On Mac, button clicks don't actually steal focus about focus-visible HOT 3 CLOSED

@bradkemper so, you're advocating for something like onmousedown on a <button> we would set focus back to the previously focused element? If so, I'm not entirely clear what user problem that would be solving. I also think what you're asking for is outside the scope of what this library is aiming to solve and a bit against the grain; we're not seeking to normalize how browsers manage focus, rather simply provide a new API for styling focus gained through keyboard actions.

While we developers are aware of the subtle differences between how focus is handled differently on Mac and Windows, those behaviors are expected by users and therefore we'd best serve users by honoring them, rather than making a Windows browser behave like a Mac browser.

That said, if you wanted to prevent any non-text input elements from gaining focus in your own applications you could implement that easily by simply binding a document-level event listener that would prevent the target from gaining focus by calling preventDefault(). Here's a simplified example:

document.addEventListener('mousedown', function(e) {
  var tagName = e.target.tagName.toLowerCase();
  if (tagName == 'textarea') {
  	return;
  }

  e.preventDefault();
}, true);

If I misread your intention with this issue, can you clarify what you are asking for and what user problem you are addressing?

from focus-visible.

It is less about normalization between platforms, and more about fixing non-standard behavior within browsers of a single platform. Inasmuch as this library tries to get the browser focus rendering to look more like what focusing does in other desktop apps, I thought it would be nice to also more fully emulate the focusing behavior of other desktop apps too. Personally, I think the Mac behavior would be good on other platforms too, but if that is unexpected then maybe UA detection would be warranted.

In terms of what this behavior solves, and why Macs have it: it means that in places where you are typing into fields or areas, where you might also want to click on a button, doing so will not interrupt your typing and force you to refocus the field and insertion point. You can type some words, click on a button (imagine a toolbar button in MS Word, for example), and then continue typing. It is similar even in small text fields of OS X input sheets, such as a standard print dialog box. Changing the paper size doesn't blur the field for typing in number of copies, unless you use the keyboard to tab out of it and tab into the paper size menu. This is just standard behavior on the Mac (except in browsers), and why the focus rings are visible when they are. For mouse users, the focus ring indicates something you can type text into.

Preventing a mousedown event is likely to have some unwanted side effects, besides just focusing. For instance, the standard behavior on the Mac is that pop-up menus (SELECTs) can be activated with just a mousedown (without actually changing the focus, which is how Web pages are different), and that standard behavior would probably be prevented if preventDefault was called.

from focus-visible.

Thanks for the thoughtful discussion guys.

While we developers are aware of the subtle differences between how focus is handled differently on Mac and Windows, those behaviors are expected by users and therefore we'd best serve users by honoring them, rather than making a Windows browser behave like a Mac browser.

I agree with @kloots on this one. The :focus-ring pseudo selector is primarily for exposing a styling hook based on input modality. @bradkemper has a good point that it's definitely quirky, but it's out of scope for this little library to try to tackle that issue. We're not trying to correct or normalize the way focus actually behaves on different platforms. If it's ok i'm going to close this issue as out of scope.

from focus-visible.