:focus-visible in WebKit - May 2021
And again this is a new report about the work around :focus-visible
in WebKit, you can check the previous ones at:
As you might already know this work is part of the Open Prioriziatation campaign by Igalia that has been funded by a lot of people. Thank you all for your support!
The high level summary is that the implementation in WebKit can be considered to be complete and all the :focus-visible
patches have been included on the last Safari Technology Preview 125 as an experimental feature. Moreover, Igalia has been in conversations with Apple trying to find a way to enable the feature by default at some point.
Implementation details #
As I’ve just mentioned, the implementation finished by the end of April, and no more patches have landed since then. It passes most of the WPT tests, there are still some minor differences here and there (like some input types matching or not :focus-visible
) but those issues have been considered to be fine as they depend on the different browsers specific behavior.
You can test this feature in Safari Technology Preview (since release 125) by enabling the runtime flag in the menu (Develop > Experimental Features > :focus-visible pseudo-class). Please play with it and report any issue you might find.
Debate time #
During the last patch reviews more Apple engineers got interested on the feature, and there were a bunch of discussions about whether it would (or should) change the default behavior in WebKit, and how.
So let’s start from the beginning, what is focus-visible
? A broad description of :focus-visible
is that it will match based on when the browser would natively show a focus ring. The typical example for this are buttons, in general when people click a button they don’t expect to see a focus ring, for that reason most browsers haven’t been showing it for years. When an element is focused browsers use some internal heuristics to decide when to show or not a focus ring.
However buttons in Safari are different to other browsers, and that’s because Safari follows the Mac platform conventions. Buttons are not click focusable in Safari (though you can still focus them via keyboard with Option + Tab), as they don’t receive focus on click they don’t even match :focus
, so they never show a focus ring on mouse interactions. This behavior tries to mimic what happens on the Mac platform, but there are still some differences. The Mac platform standard, for example, allows that you can be editing an input, click on a button and keep editing the input as the focus is still there. However that’s not exactly what happens in Safari either, when you click the button, even if it doesn’t get the focus, the focus is gone from the input, so you cannot just continue editing it like in the platform. On top of that, an invisible navigation caret moves to that button on click, and further keyboard navigations start from there. So it’s kind of similar to the platform, but with some nuances.
This is only part of the problem, the web is full of things that are focusable, like <div tabindex="0">
elements. These elements have always matched (and still match) :focus
by default, and have usually showed a focus ring when focused via mouse click. Web authors generally want to hide the focus ring when clicking on <div tabindex="0">
elements, and that’s why the current :focus-visible
implementations don’t match in this case. Chrome and Firefox are using :focus-visible
in the User Agent (UA) style sheet, so they don’t show a focus ring when clicking on such elements. However, Apple has expressed some concerns here that it might change the default focus indicator behavior in a way that might differ from their platform philosophy, and thus needs more review.
During these conversations an idea showed up as potential solution. What if we show a focus ring when users click on a generic <div tabindex="0">
, but we don’t if that element has some specific role, e.g. <div tabindex="0" role="button">
. This would give web authors the possibility to get their desired behavior by just adding a role to those elements.
This would make <div tabindex="0" role="button">
work similar to regular buttons on Mac, but there’s still one difference, those elements will still get the focus so some use cases might get broken. James Craig came out with a scenario in which an user is scrolling the page with the spacebar, then they click on a <div tabindex="0" role="button">
, and if they enter spacebar again, that wouldn’t keep scrolling the page anymore. And the user won’t know exactly why, as they haven’t seen any focus ring after click (note that with the current :focus-visible
implementation, they user will start to see a focus ring on that <div tabindex="0" role="button">
after entering the spacebar).
On that discussion James has shared an idea to add a new CSS property (or it could be a HTML attribute) that marks an element so it cannot receive focus via mouse click. That would make possible to make buttons work like in Safari in other browsers, or make a <div tabindex="0">
to work like a Mac button too. However this would be something new that would need to get implemented in all browsers, not just WebKit and that would need to get discussed and agreed with the web community.
On the same issue Brian Kardell is proposing some alternatives, for example having some special parameter like :focus-visible(platform)
(syntax to be defined) that could behave differently in Safari than other browsers, so Safari can use it in the UA style sheet, while :focus-visible
alone would work the same in all browsers.
As you see there’s not a clear solution to all this discussion yet, but we’re following it closely and providing our feedback to try to reach some final proposal that makes everyone happy.
Some numbers #
Let’s do a final review of the total numbers (as nothing has changed in May):
- 26 PRs merged in WPT.
- 27 patches landed in WebKit.
- 9 patches landed in Chromium.
- 2 PRs merged in CSS spcs.
- 1 PR merged in HTML spec.
Wrapping up #
:focus-visible
has been added to WebKit thanks to the support from many individual people and organizations that make it happen through the Open Prioritization experiment by Igalia. Once more big thanks to you all! 🙏
In addition, the WPT test suite has been improved counting now ~40 tests for this feature. Also in January neither Firefox or Chrome were using :focus-visible
on the UA style sheet, however they both use it there nowadays. Thus, doing the implementation on WebKit has helped to move forward this feature on different places.
There is still the ongoing discussion about when or how this could be enabled by default in WebKit and eventually shipped in Safari. That conversation is moving and we hope there’ll be some kind of positive resolution so this feature can be enjoyed by web authors in all the browser engines. Igalia will keep being on top of the topic and pushing things forward to make it happen.
Finally, thanks to everyone who has helped in the different conversations, reviews, etc. during these months.
- Previous: :focus-visible in WebKit - April 2021
- Next: Igalia 20th Anniversary