I think this is small and relatively non-controversial. It's existed in Gecko for a while as :-moz-focusring.

I guess the biggest thing I wonder about when reading the specification is whether the conformance criteria should be as loose as they are, or whether they should be a little bit more specific. I guess it's probably fine as they are.

So, basically, I think this is fine.

I think that there are a few cases where we actually have verified through use of the polyfill and feedback from some fairly widely used sites/apps that we would kind of not want it to match exactly what :-moz-focusring does. In spirit, yes, it is the same animal... Agree that we don't want to get too over-specified about it but we were working on a pull that describes it better.. Maybe we should finish that? I think it might be worth looking at the tests, if the tests are up to date (honestly, @robdodson would know a lot better at this point)? So... idk, fwiw, I do think we may want it to be just a little more wordy, at least in the note about intent if not actually specified strict conformance criteria?

Yep the tests are up to date :) As Brian mentioned, we are working on a PR to better describe the intent and we might delve a bit more into conformance. We can follow up on this thread when we've refined that language.

We've sent a PR to the spec to try to better spell out the intent of the selector and give a bit more conformance criteria.

https://github.com/w3c/csswg-drafts/pull/2481

session scheduled for Saturday on this

We took a look at the PR, and will cycle back again in a few weeks.

Maybe this is my lack of understanding, but if I target an element with both :focus and :focus-visible in a stylesheet, won't the :focus rule make the :focus-visible rule never work? (Since :focus always applies when an element is in focus, and :focus-visible conditionally applies?) So, if I, as a developer, want to start using :focus-visible in my stylesheet for UA's that support it, but keep :focus around for those that don't, I guess I must resort to @supports? Or is it understood somehow that :focus-visible wins over :focus assuming specificity is otherwise equal?

Nothing special about this, basically, so yes... whatever wins, wins. That seems pretty standard css fare though. A better temporary option is probably to use the speculative polyfill and avoid :focus altogether.

A big part of the issue here is that because :focus doesn't match UA styles there's really no 'good' way to use it on many sites. Using it negatively impacts user experience by either showing indicators when they shouldn't or (surprisingly often) just never showing them at all because people can't work out how to avoid the too often problem.

I agree that if you want :focus rules only for UAs that don't support :focus-visible, they would need to be in an @supports rule, although currently you can't test selector support with @supports rules, so it's not actually doable. (We need to add that at some point; we might even have a WG resolution to do so...)

OK. Glad to get that confirmed. Thanks!

Adding pseudo classes to @supports would be a huge help.

As Brian mentioned, without @supports, using the polyfill may be the easiest way to provide backwards compatibility.

Another possible trick suggested by the Paciello Group would be to do something like:

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 */ }

I haven't tested it across all browsers, but the author suggests that if the browser doesn't know about the pseudo class in the :not() bit, then it ignores the entire selector.

Still waiting on status / fate of w3c/csswg-drafts#2481 ... we will keep this open for now and come back to it.

I chatted with @tabatkins today, he said he wanted to take a stab at updating the spec text based on our discussion and some of the content in the linked PR.

Seems that the CSS WG discussion has now moved to w3c/csswg-drafts#2897, which is still open.

That PR is now merged, so the text is now part of the spec.

Looks great to me!

The TAG reviewed the merged PR and is satisfied with the result. Thanks everyone for your participation, and we hope you consider us for your future reviews!