Add section about when to draw or not a focus ring

[mrego]

This section describes a set of heuristics to determine if the currently focused element should have or not a focus ring.

This has the goal to get consensus between the different UAs about the expected behavior. This used to be a non-normative text in the :focus-visible CSS spec, but it's now an example there. The CSSWG has suggested that CSS shouldn't take care of defining when the UA should show or not a focus ring, and that should be part of HTML spec directly (see discussion at w3c/csswg-drafts#5885 (comment)).

Current implementations agree in most of the things defined here, except the script focus behavior (which is not implemented in WebKit yet, and is not interoperable in a few cases between Chromium and Firefox).

The script focus part has been discussed with different tests cases in a WPT PR and it looks there's agreement about what are the expectations in the different cases. The proposed spec text is trying to reflect that.

I'm adding the relevant folks on CC so they can provide their input here and agree or not with this change: @alice @bkardell @emilio @robdodson.

Implementations bugs will be filled as needed once there's consensus on the spec text.

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • 20 :focus-visible tests in css/selectors
  • Script focus tests: [selectors] Add tests related to script focus and :focus-visible web-platform-tests/wpt#27806
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: …
  • Safari: …

---

/index.html ( diff )
/interaction.html ( diff )

[rniwa]

This sounds very mobile centric way of defining things. I don't think it would appropriate define a normative text based on examples.

[robdodson]

@alice what do you think about removing the parenthetical?

[robdodson]

thinking about this a bit more... I think we originally included that example because just saying something supports keyboard input can be kind of vague. For example, you can press spacebar to click a button, but we don't want buttons to have a focus ring unless interacted with via keyboard.

Really I think we meant "the control expects you to type some characters" which is why we provided that virtual keyboard example. I'm curious if folks have any idea on how best to express that.

[mrego]

Thanks for the feedback.

Good point, this is not very normative text, so I'm going to give a try to a different way to describe this (this is similar to another place on the HTML spec):

If the currently focused element is a text control, an editing host or an editable element.

For the purpose of this point, a text control is a textarea element or an input element whose type attribute is in one of the Date, Local Date and Time, Email, Number, Password, Search, Tel, Text, Time, URL, or Week, states.

I'm going to upload a new version using this text and also updating a little bit the rest (as there was another point referring to "the focused element does not support keyboard input" which is not very clear either.

[rniwa]

I don't think we can explicitly enumerate a set of input types like that. In some OS, for example, type=date may not be keyboard typable.

[mrego]

I've been testing the behavior of different browsers on different platforms.

<select> is a special one. It shows a focus ring in mobile in all browsers in all platforms (iOS and Android), and also shows it on desktop (except on Firefox where it doesn't show it on desktop; and on Chromium that hides it while the pop-up is open, but shows it once you've selected the element). Maybe an option could be to include select on this list and change Firefox behavior on desktop.

Apart from that, things that <input type="date">, despite you cannot use them with the keyboard on mobile, they show a focus ring in both iOS and Android (Chromium and Firefox) while you're selecting the date. Though maybe that's not intentional, but it's the current behavior.

So one option could be to include <select> on the explicit list of things.

Another option I see is to use some open definition, like "the element supports keyboard input" and let browsers decide what to do depending on the platform. Dunno if something like that would be acceptable for normative text.

Any other idea or suggestion is welcomed, as I'm running out of ideas about how to define this thing.

[bkardell]

what if we revise for that case in a generic way "If the control accepts keyboard input such that it would paint typed characters to the screen, or acts as a proxy to selecting from a list of options" is a way to split the difference here?

[mrego]

I've followed @emilio suggestion on the last version.

So it mentions text control, editing host or editable element.
Defines that text controls are textarea and input with types: email, password, search, text and url.
And then adds "The user agent may draw a focus ring in other elements".

Could that be good enough?

[robdodson]

@rniwa wdyt?

[rniwa]

Now that I understand the ramifications from this spec text, I'm wondering why this text was added at all. The idea of non-editable controls not getting focus ring in WebKit comes from the fact they don't get the focus in the first place, not just the drawing of the focus ring.

[emilio]

I think defining normatively the cases where we all agree and leaving a more generic "The user agent may show focus rings in other situations" seems like reasonable progress here.

[othermaciej]

I don't think a spec should define when to draw focus rings. As I understand it, the point of :focus-visible is to let authors style only in the case where the UA would have drawn a focus ring, precisely because this is left to UA discretion. Even if all current browsers on all current platforms agree, browsers should be free to follow future platform conventions that may differ from any existing ones.

[mrego]

Ok, let's close this. Thanks everyone for the feedback.