Csswg-drafts: [css-selectors-4] browser focus styles and focus-visible, example 38

[frivoal]

My understanding of :focus-visible was that it gave authors access to the existing logic by which browsers style focused elements, so that authors could change that, without adding focus indicators onto things where the browser wouldn't, which is what would happen if they used :focus instead.

However, the spec, and in particular example 38, suggest that authors could write something like:

:focus:not(:focus-visible) {
  outline: 0;
}

in order to suppress browser-supplied focus indicators on elements that match :focus but not :focus-visible.

That's very confusing to me, as by my understanding, there should be no such element. The sentence immediately before the example also seems to agree with me.

Maybe that selector is meant as a poor man's @support for selectors, but it's given what the rest of the example does, it's not needed or useful.

If I'm right, this example is causing confusion and inducing authors to think that they need to use :focus:not(:focus-visible) to select and suppress undesirable browser styles, which is just not true. In that case, this should be removed from the example.

If I'm wrong, I'd like to understand why, because then the feature no longer makes sense to me.

[mrego]

I think that while the default stylesheet on the UAs are using :focus and not :focus-visible, the way to go is to use this :focus:not(:focus-visible) and disable the focus ring in that case.

For example you have a <div tabindex="1">Click me!</div>, when you click it, it gets focused, so it's going to match :focus, but it's not going to match focus-visible.
Chromium is still using :focus in the UA stylesheet, so unless you do something like that, you won't be able to get rid of the focus ring in those cases. I haven't checked what Firefox does.

CC @alice @emilio @robdodson

[emilio]

Which UA sheet is using :focus but not :focus-visible to show outlines? I'd consider that a bug.

[emilio]

(AFAICT in Gecko all UA sheets use :-moz-focusring. when :focus-visible is enabled they are equivalent)

[mrego]

Chromium is using :focus in the UA sheet, probably it should switch to :focus-visible now that it has shipped.

WebKit uses :-webkit-direct-focus (it doesn't support :focus-visible yet).

[mrego]

I believe that the problem might be that Chromium has implemented something different than what the initial idea was, and that's why this confusion arise. Maybe I'm wrong but let's me explain my thoughts next.

The spec says:

The :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the user agent determines via heuristics that the focus should be made evident on the element.

So let's use again a very simple example:

<div tabindex="1">Click me!</div>

When you click on that element Chromium (and WebKit) shows an outline, however in Chromium it doesn't match :focus-visible. This seems to be a contradiction to the initial text on the spec.
In Firefox it doesn't show any outline, so :focus-visible doesn't match either, but that seems to be the expected behavior.

I guess Chromium is implementing this other part of the spec:

If the user interacts with the page via a pointing device, such that the focus is moved to a new element which does not support user input, the newly focused element should not match :focus-visible.

So if Chromium decides to change the UA sheet to use :focus-visible there'll be a change of behavior in those cases, when you click an element like the one in the example the outline would be gone after the change in the UA sheet.
Maybe that's what we want in order to look for interoperability in when the focus ring is shown or not.

It'd be nice to understand why Chromium did this and why the UA sheet is still not using :focus-visible.

[emilio]

I think this is just a Chromium bug, tbf. Chromium should be using :focus-visible in the UA sheet.

[mrego]

I think this is just a Chromium bug, tbf. Chromium should be using :focus-visible in the UA sheet.

I agree, I've just reported https://bugs.chromium.org/p/chromium/issues/detail?id=1162070

And also created a test that fails in Chromium due to this (and pass in Firefox) at https://github.com/web-platform-tests/wpt/pull/27015