Intent to implement :focus-visible pseudo class.
robd...@chromium.org
Contact emails
Spec
https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo
WICG Explainer
https://github.com/WICG/focus-visible/blob/master/explainer.md
Design Doc
https://docs.google.com/document/d/1HeGGnAX2T8RlSoeF4f_hxPWlMMHR6uIkkSbKIdRCy7Y/edit?usp=sharing
TAG Review
https://github.com/w3ctag/design-reviews/issues/233
Summary
CSS Selectors 4 introduces the focus-indicated pseudo-class :focus-visible.
Motivation
Quoted from the WICG explainer:
The status quo, :focus, is quite problematic:
Many developers disable the default focus ring in their CSS styles, others attempt to style it in concert with their design. The former often seems to be a result of finding the default focus ring both aesthetically unpleasant and confusing to users when applied after a mouse or touch event and introduces accessibility problems. The latter inevitably creates considerably more of the kind of problem that the former was trying to solve.
Some native elements in some browsers, notably <button> in Chrome, have a "magic" focus style which does not apply unless focus was received via a keyboard interaction.
To deal with this:
It seems evident that a visual indication of what has focus is primarily interesting to a user who is using the keyboard to interact with the page. A user using any kind of pointing device would only be interested in what is in focus if they were just about to use the keyboard - otherwise, it is irrelevant and potentially confusing.
Thus, if we only show the focus ring when relevant, we can avoid user confusion and avoid creating incentives for developers to disable it.
A mechanism for exposing focus ring styles only when the keyboard is the user's current input modality gives us this opportunity.
Risks
Interoperability and Compatibility
There should be low interoperability risk as no other browser currently ships :focus-visible and the implementation in Chromium will closely match that of :-moz-focusring.
The only notable difference between :focus-visible and :-moz-focusring is that :focus-visible in Chromium will not match on elements with tabindex when they are focused via a mouse or touch. This is because any custom component—whether built out of generic elements like <div>, or built as a Custom Element—will need to self-apply a tabindex in order to be keyboard operable. But the mere presence of tabindex is not a strong enough signal to indicate that an element should always display a focus indicator.
For example, if a developer is building a Custom Element button, they may wish for the behavior to exactly match that of <button> and only display a focus indicator on keyboard focus, not mouse or touch focus.
Ergonomics
No performance issues are expected to be introduced by this feature.
Activation
This feature will initially be implemented behind a flag.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Feature dashboard link
https://www.chromestatus.com/feature/5823526732824576
Requesting approval to ship?
No. We will keep the feature behind a flag and work with at least one other browser to make sure our implementations are in alignment before we request permission to ship.
Ongoing technical constraints
None.
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=817199
TAMURA, Kent
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b1bd1969-8846-47b0-a8db-dd38a4997c62%40chromium.org.
Software Engineer, Google