Hey Florens, I worked on the Chrome implementation of :focus-visible with Alice Boxhall.

Is the behavior in Chrome's implementation what you'd want/expect?

Our thinking on the Chrome side has been that the semantics of the action should define whether or not a focus ring gets displayed (and if :focus-visible will match). Our general rule of thumb has been that if you were to click on a control on mobile, would it display a virtual keyboard? If "yes" then :focus-visible should match, regardless of the input modality (mouse, keyboard, pointer, etc). If the answer is "no" then :focus-visible will not match for mouse/touch/pointer, but it would match for keyboard focus.

So if you mouse click on an input, it will always match :focus-visible.
Whereas if you mouse click on a button, it will not match :focus-visible.

Hi Rob. In my tests the behavior in Chrome matched my expectations (but to be clear I only tested on desktop + mouse and desktop + keyboard).

One issue I had was that :focus-visible was in practice the same as :focus for text inputs. I understand the rationale, but it made it harder to pass design review with a fully accessible design. I could not provide a "subtle" :focus style and a more visible :focus-visible style like this:

input[type="text"] {
  border: solid 1px #bbb;
}

input[type="text"]:focus {
  border-color: rgba(100, 100, 255);
}

input[type="text"]:focus-visible {
  border-color: blue;
  box-shadow: inset 0 0 0 1px blue,
    0 0 0 3px rgba(100, 100, 255, 0.5);
}

In design review I was asked to only keep the 1px border color change for the majority use case of users clicking the text input, which rules out using :focus-visible there with Chrome's implementation.

I can probably live with that though. In other projects having strongly visible focus styles on text inputs was not an issue.

I tried to use :-moz-focusring for perf-html too, and I found that the behavior isn't what I expect from :focus-visible. As Florens said I couldn't find a difference between :-moz-focusring and :focus.

Chrome implementation makes sense, except I agree with Florens about the behavior for <input text> though: probably this would give more flexibility to web developers by implementing it the same way as for <button>.

So here's a current description of what :-moz-focusring is doing:

• If browser.display.show_focus_rings=true (Windows and Linux), then it's the same as :focus, effectively.
• If it's false, then once you tab navigate, it becomes "true" for that document.

So it seems :focus-visible should be somewhat different to :-moz-focusring. In particular it should not be stateful.

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Emilio's been working on this, so marking as ASSIGNED.

It has been enabled in Chrome 86 without a flag: https://bugs.chromium.org/p/chromium/issues/detail?id=817199#c28

I see that example on https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible in Firefox 81 Nightly almost works (it matches focus-visible on keyboard focus), without a flag as well.
Does it mean we can expect it in 81 with some fixes which will align it with the chrome behavior?

Hi! The :focus-visible experimental flag doesn't seem to work as intended in Firefox 84.0. :focus-visible styling is activated whenever an element is focused, even by a click event. (As Pavel noted, without the experimental flag enabled, the default :focus styling is applied on both keyboard and click focus.) I tested both ways on Mozilla's documentation of the pseudo-class.

Emilio, is this still on your radar? Is this behavior expected at this point, and is there any roadmap for a release of :focus-visible with updated behavior and without a flag?

Apologies if these sorts of questions don't adhere to Bugzilla Etiquette, by the way! I reviewed the guidelines and think it's ok, but I'm new here :)

Can you elaborate, does :focus-visible incorrectly apply? Do you have a test-case? Or does the browser use focus rings? The browser uses :-moz-focusring for the time being, and unifying them is basically the precondition to ship this I suspect.

Yes, with :focus-visible enabled in my Firefox config, clicking on the button and input field labeled "focus visible only" here applies the orange dotted focus ring. When clicking on the same button and field in Chrome, which implemented :focus-visible by default in v86, the orange focus ring does not appear; it's only applied when the user navigates to these elements using their keyboard, which is the expected behavior.

I cannot reproduce that, what OS are you on? And, can you file a separate bug about it instead?

Oh, or it may be that you have navigated by keyboard before. Firefox enables focus outlines on all elements once you've done keyboard navigation (but not before).

Firefox enables focus outlines on all elements once you've done keyboard navigation (but not before).

IMHO this is bound to create countless bug reports by clients and QA (similar to the report by Cara Price in this thread), and endangers :focus-visible as a viable solution.

I think the JavaScript focus-visible polyfill uses a more fine-grained approach, which avoids this pitfall?

(In reply to Florens Verschelde :fvsch from comment #20)

I think the JavaScript focus-visible polyfill uses a more fine-grained approach, which avoids this pitfall?

Well, it's not a pitfall, IMO, it's how various OSes have behaved historically. But anyhow I filed bug 1677376 to give this a shot.

Intent email, hopefully with a nice executive summary: https://groups.google.com/g/mozilla.dev.platform/c/yA2rL_2keTE/m/V0ZRCykZAAAJ

https://hg.mozilla.org/mozilla-central/rev/868161e8c855

I have updated BCD for this feature and added a release note for Firefox 85.