[Webkit-unassigned] [Bug 225148] [selectors] :focus-visible and keyboard events

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=225148

Rob Dodson <robdodson at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robdodson at chromium.org

--- Comment #16 from Rob Dodson <robdodson at chromium.org> ---
One of the intentions of :focus-visible is to not match if someone mouse-clicks on a div (or other generic element) with a tabindex because developers often build custom controls using generic elements and when they unexpectedly show a focus ring on mouse click these same developer reach for :focus { outline: none; } which we really want to discourage.

The spec attempts to explain that :focus-visible should not match when you mouse click an element with a tabindex, but does so in a way that maybe isn't explicit enough. Quoting from the spec:

> If the element which supports keyboard input (such as an input element, or any other element that would triggers a virtual keyboard to be shown on focus if a physical keyboard were not present), indicate focus.
This attempts to highlight the concept of "supporting keyboard input". Notably a div with a tabindex would not meet this criteria.

> If the user interacts with the page via a pointing device (mouse, touchscreen, etc.) and the focused element does not support keyboard input, don’t indicate focus.
The key phrasing here is "and the focused element does not support keyboard input". Since a div with a tabindex does not support keyboard input then it should not match :focus-visible when mouse-clicked. If, however, someone were to add contenteditable to the div, then it would meet the criteria and :focus-visible would match.

> Perhaps it should depend on the role or other functionality, more than the tag. For example, in the case of <div tabindex="0" role="textbox" contenteditable>, I would expect click-focus to show the focus outline. In the case of <div tabindex="0" role="button">, maybe not.

I think this is resolved by the point above. When designing the feature we often came back to the question of when is a custom control "button-like" versus "input-like". `contenteditable` seems to be a good indicator that something is "input-like", so :focus-visible will match if it's present. Otherwise it's assumed to be button-like.

> The spec text that is ambiguous to me is "supports keyboard input." For example, <select> (and custom ARIA equivalents) can support keyboard input in the form of arrow keys or typeahead to change selection. Does that ability necessitate `focus-visible` even though there is no text input "value" associated as with <input type="text">?

That's a great question and one that came up on GitHub (https://github.com/w3c/csswg-drafts/issues/5822). At the time we decided that it was one of those "the browser gets to decide" situations. So Chrome says that select is input-like and Firefox says that it's button-like. I don't personally have a strong opinion on which option is correct and am sort of curious to see which one users and developers prefer.

> We should try to show it right away in places we believe will receive typing, even if the user clicked to focus it in the first place.

I think(?) we all agree that if you're clicking on a control that can receive text input, or an element with contenteditable, that we should show a ring. If that's not happening maybe it's a bug in the implementation or perhaps I'm missing something ��

> Incidentally, perhaps this UA stylesheet rule to suppress drawing a focus ring in some cases should instead be changed to be part of the definition of :focus-visible (and then other UA stylesheet rules should use :focus-visible instead of :focus).

For what it's worth I think it is called out at the end of the :focus-visible spec that browser should switch the UA stylesheet to use the :focus-visible behavior:

> User agents should also use :focus-visible to specify the default focus style, so that authors using :focus-visible will not also need to disable the default :focus style.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210505/5ec796a9/attachment.htm>