Intent to Ship: :focus-visible pseudo-class
Alice Boxhall
Contact emails
abox...@chromium.org, robd...@chromium.org, dmaz...@chromium.org
Explainer
https://github.com/WICG/focus-visible/blob/master/explainer.md
Spec
https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo
TAG review: https://github.com/w3ctag/design-reviews/issues/233
Summary
The :focus-visible pseudo-class applies while an element when an element receives focus, and the user agent determines that focus should be visible to the user.
A visual indication of what has focus is only 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.
If we only show the focus ring when relevant, we can avoid user confusion and avoid creating incentives for developers to disable it, while allowing authors to provide clearly identifiable focus styles to be used in contexts when a user is likely to want to see them.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/-wN72ESFsyo/leH6DuuhAwAJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
http://web-platform-tests.live/css/selectors/focus-visible-001-manual.html
Debuggability
Developers may toggle the :focus-visible state from the "Force element state" feature in the Elements panel.
Risks
Interoperability and Compatibility
Edge: Supportive
Firefox: Partially shipped an earlier version, bug open to update: https://bugzilla.mozilla.org/show_bug.cgi?id=1445482
Safari: Open bug for implementation: https://bugs.webkit.org/show_bug.cgi?id=185859
Web / Framework developers:
Positive examples:
https://twitter.com/davatron5000/status/1154038311817584641
https://twitter.com/SaraSoueidan/status/1167748256811638784
https://twitter.com/LeaVerou/status/1042912606024069120
Polyfill use is increasing: https://npm-stat.com/charts.html?package=focus-visible&from=2019-02-01&to=2019-11-07
Negative example:
https://css-tricks.com/focusing-on-focus-styles/#article-header-id-2 (essentially, "focus should always be visible")
There are some "open discussions", largely regarding the heuristics used:
What's the impact on users with low vision or cognitive impairments?
This would require user research to answer reliably. See also below re: opting in to always-on focus styling.
Should :focus-visible match when returning focus or programmatically focusing?
The current implementation matches when a programmatic focus occurs after a user user has interacted via the keyboard, as long as no mouse interaction has occurred in the interim. So, if a user has (for example) dismissed a dialog via the keyboard, :focus-visible will match on the element that focus is set to programmatically as a result.
Brainstorm: options for opting in to always matching focus ring.
Chrome OS has a setting to always show a visible focus ring (the ring is drawn by the OS on a separate layer). If this setting is enabled, :focus-visible will match on the focused element at all times. We may consider adding a similar setting and functionality to Chrome Browser in the future.
Ergonomics
Are there any other platform APIs this feature will frequently be used in tandem with?
Potentially :focus and/or @supports selector(), as noted below.
Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
No.
Activation
Good article on opting in to using :focus-visible before it is supported in all user agents: https://developer.paciellogroup.com/blog/2018/03/focus-visible-and-backwards-compatibility/
TL;DR:
button:focus { /* some exciting button focus styles */ }
button:focus:not(:focus-visible) {
/* undo all the above focused button styles
if the button has focus but the browser wouldn't normally
show default focus styles */
}
button:focus-visible { /* some even *more* exciting button focus styles */ }
If CSS's @supports selector() function is implemented, that may be used to check for support.
Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.
https://wpt.fyi/results/css/selectors?label=master&label=experimental&aligned&q=focus-visible
(Some tests are excluded from this result as they are manual tests.)
Entry on the feature dashboard
https://www.chromestatus.com/feature/5823526732824576
Future work
Ideally, we should work towards switching the default focus behaviour for all non-text input elements to match :focus-visible, both via the UA stylesheet and the ShouldHaveFocusAppearance() method on Node. This would remove one incentive for developers to "undo" default focus appearance via outline: none.
TAMURA, Kent
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLydLtuMmJmdMV0ynje%3Dn15vTFcKMJweMQU2Zpqw7xPWXQ%40mail.gmail.com.
Software Engineer, Google
Emilio Cobos Álvarez
> LGTM1. Firefox already has a prefixed one, and WebKit recently
> introduced an equivalent one, :-webkit-direct-focus. I guess every major
> browser will implement :focus-visible.
it seems just an implementation detail. But I could be wrong of course.
-- Emilio
[1]: https://trac.webkit.org/changeset/250788/webkit
> <mailto:abox...@chromium.org>> wrote:
>
> Contact emails
>
> abox...@chromium.org <mailto:abox...@chromium.org>,
> robd...@chromium.org <mailto:robd...@chromium.org>,
> dmaz...@chromium.org <mailto:dmaz...@chromium.org>
>
>
> Explainer
>
> https://github.com/WICG/focus-visible/blob/master/explainer.md
>
>
> Risks
>
> Interoperability and Compatibility
>
>
> Edge: Supportive
>
> Firefox: Partially shipped an earlier version, bug open to update:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1445482
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1445482>
>
> Safari: Open bug for implementation:
> https://bugs.webkit.org/show_bug.cgi?id=185859
> <https://bugs.webkit.org/show_bug.cgi?id=185859>
>
>
> Web / Framework developers:
>
> Positive examples:
>
> https://twitter.com/davatron5000/status/1154038311817584641
>
> https://twitter.com/SaraSoueidan/status/1167748256811638784
> <https://twitter.com/SaraSoueidan/status/1167748256811638784>
>
> https://twitter.com/LeaVerou/status/1042912606024069120
>
> Polyfill use is increasing:
> https://npm-stat.com/charts.html?package=focus-visible&from=2019-02-01&to=2019-11-07
> <https://npm-stat.com/charts.html?package=focus-visible&from=2019-02-01&to=2019-11-07>
>
>
> Negative example:
>
> https://css-tricks.com/focusing-on-focus-styles/#article-header-id-2
> <https://css-tricks.com/focusing-on-focus-styles/#article-header-id-2>(essentially,
> "focus should always be visible")
>
>
> There are some "open discussions
>
> What's the impact on users with low vision or cognitive impairments?
>
> *
> This would require user research to answer reliably. See also
> below re: opting in to always-on focus styling.
>
> Should :focus-visible match when returning focus or programmatically
>
> *
> The current implementation matches when a programmatic focus
> occurs after a user user has interacted via the keyboard, as
> long as no mouse interaction has occurred in the interim. So, if
> a user has (for example) dismissed a dialog via the keyboard,
> :focus-visible will match on the element that focus is set to
> programmatically as a result.
>
> Brainstorm: options for opting in to always matching focus ring.
>
> *
> Chrome OS has a setting to always show a visible focus ring (the
> ring is drawn by the OS on a separate layer). If this setting is
> functionality to Chrome Browser in the future.
>
>
>
> Ergonomics
>
> Are there any other platform APIs this feature will frequently be
> used in tandem with?
>
>
> Could the default usage of this API make it hard for Chrome to
> maintain good performance (i.e. synchronous return, must run on a
> certain thread, guaranteed return timing)?
>
> No.
>
>
> Activation
>
> Good article on opting in to using :focus-visible before it is
> supported in all user agents:
> https://developer.paciellogroup.com/blog/2018/03/focus-visible-and-backwards-compatibility/
> <https://developer.paciellogroup.com/blog/2018/03/focus-visible-and-backwards-compatibility/>
>
>
> TL;DR:
>
> button:focus{ /* some exciting button focus styles */}
>
> button:focus:not(:focus-visible){
>
> /* undo all the above focused button styles
>
> if the button has focus but the browser wouldn't normally
>
> show default focus styles */
>
> }
>
> button:focus-visible{ /* some even *more* exciting button focus
> styles */}
>
>
> If CSS's @supports selector()
>
>
> Is this feature fully tested by web-platform-tests
> Link to test suite results from wpt.fyi <https://wpt.fyi>.
>
> https://wpt.fyi/results/css/selectors?label=master&label=experimental&aligned&q=focus-visible
>
> (Some tests are excluded from this result as they are manual tests.)
>
>
>
> https://www.chromestatus.com/feature/5823526732824576
>
>
> Future work
>
> Ideally, we should work towards switching the default focus
> behaviour for all non-text input elements to match :focus-visible,
> both via the UA stylesheet and the ShouldHaveFocusAppearance()method
> on Node. This would remove one incentive for developers to "undo"
> default focus appearance via outline: none.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMQHGLydLtuMmJmdMV0ynje%3Dn15vTFcKMJweMQU2Zpqw7xPWXQ%40mail.gmail.com
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHGO_Df7VbBwaLUMYVXaXkAJJi7kNN9C1p0xS-1UWHmPA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
TAMURA, Kent
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/368a5a7e-f65e-b0ea-93ce-6ef9d8bab7e7%40mozilla.com.
Daniel Bratell
Nice addition. I agree with what others have said, this ought to
become a commonly used feature.
LGTM2
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqGdZww4-tKjsGWWCUBFFSvsoiDYeouZV8XSNRX0sZsbKQ%40mail.gmail.com.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb4f65f8-84ee-bc65-2e83-f8165a537c7a%40gmail.com.