-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: extend FocusOptions to allow specifying :focus-visible
behavior.
#7830
Comments
I guess trying to be smart about when to show it or not won't catch all the use cases, as we're seeing. So maybe this could be a solution for that problem. I wonder what people that were involved in the |
Any reason for the name Also, we don't need to make it nullable; it's a dictionary member so it would already be optional. |
Not really, I just made the name up.
Ah, indeed. Updated the OP to account for that. |
I enthusiastically support this proposal! I just switched Tableau's internal UI library over to use IMO we should also expose the current "focus-visibility" as a property in |
As per: * whatwg/html#7830 * whatwg/html#8087 Replace the internal preventFocusRing with the new flag. Differential Revision: https://phabricator.services.mozilla.com/D151326 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1765083 gecko-commit: 570b38756541697f8b5c3b8084b5a2fb438eeca9 gecko-reviewers: smaug, pip-reviewers
As per: * whatwg/html#7830 * whatwg/html#8087 Replace the internal preventFocusRing with the new flag. Differential Revision: https://phabricator.services.mozilla.com/D151326
As per: * whatwg/html#7830 * whatwg/html#8087 Replace the internal preventFocusRing with the new flag. Differential Revision: https://phabricator.services.mozilla.com/D151326 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1765083 gecko-commit: 570b38756541697f8b5c3b8084b5a2fb438eeca9 gecko-reviewers: smaug, pip-reviewers
As per: * whatwg/html#7830 * whatwg/html#8087 Replace the internal preventFocusRing with the new flag. Differential Revision: https://phabricator.services.mozilla.com/D151326
Right now, whether to show focus rings on programmatic focus is left up to the User Agent (see #6523 for some background etc).
The heuristics browsers use are mostly interoperable, but they do not cover all use cases. In Mozilla bug 1765083, someone details a use-case for forcing focus rings on programmatic focus (even when focus comes from the mouse). I think that use case is compelling, quoting:
It makes sense to show the focus ring even if the form submission was done via the mouse. Similarly, Firefox already has internal use cases for not showing the focus rings even when there hasn't been any previous focus move (which would show rings otherwise), see bug 1699259.
I think it would make sense to extend FocusOptions with something like this:
To let authors override the focus ring heuristics that the UA implements.
How does something like that sound? I think it would be reasonably straight-forward to implement interoperably and would give more flexibility to web developers.
I think at least the option to force focus rings should be uncontroversial, as the result should never be less accessible than the alternative. The option to force remove focus rings might be a bit more debatable, but I think it probably makes sense.
cc @mrego @mfreed7 @rniwa
The text was updated successfully, but these errors were encountered: