Moving away from what-input attributes for styling and relying on focus-visible.

[mannycarrera4]

We've deprecated hideMouseFocus and mouseFocusBehavior in v12. We will be removing those in v14 (September 2025). We're also going to be removing the InputProvider in v14. It uses a modified what-input which was needed to support focus rings conditional on input type for IE11. We dropped IE11 support some time ago. Using :focus-visible instead of hideMouseFocus and mouseFocusBehavior is our recommendation.

:focus-visible and our what-input solution vary slightly in edge-case details. For example, our changeFocus forced keyboard mode so that focus changes would show while :focus-visible does not do that. This is intentional and has been approved by accessibility.
There are a few edge-cases that :focus-visible cannot handle on its own - where the element being styling is not the element being focused. We had one case with Tooltips adding extra padding to account for the focus rings on buttons even though the tooltips are portalled to the body. The :has pseudo-selector takes care of these.

// Before
...mouseFocusBehavior({
  // focus style
  border: `2px solid blue`,
  '&': {
    // removes style for mouse
    border: `2px solid transparent',
  }
})

// After
'&:focus-visible': {
  border: `2px solid blue`
}

The hideMouseFocus call can be removed and any :focus replaced with :focus-visible.
If the element you are styling is not what is being focused, you can use :has instead. If you used :focus-within, :has + :focus-visible will be more accurate:

// Before
'&:focus-within': {
  // focus styles
  ...mouseFocusBehavior({
    // removing focus styles
  })
}

// after
'&:has(:focus-visible)': {
  // focus styles
}

In the case of Tooltips needing to know if something on the page has focus:

body:has(:focus-visible) &': {
  // only matches if some element on the page has focus-visible, it will match the current element (the `&`)
}