ElementInternals: Add a capability to set the default focus behavior

[tkent-google]

This commit introduces 'focusBehavior' IDL attribute of ElementInternals
interface. It accepts "unfocusable", "focusable", and "simple-control",
and affects focus behavior of ElementInternals' target element.

This fixes WICG/webcomponents#762

---

• At least two implementers are interested (and none opposed):
  • Chrome: We're interested in this.
  • TODO
• Tests are written and can be reviewed and commented upon at:
  • custom-elements: Add a test for 'focusBehavior' web-platform-tests/wpt#21063
• Implementation bugs are filed:
  • Chrome: TODO
  • Firefox: TODO
  • Safari: TODO

(See WHATWG Working Mode: Changes for more details.)

---

💥 Error: Wattsi server error 💥

PR Preview failed to build. (Last tried on Jan 15, 2021, 7:59 AM UTC).

More

PR Preview relies on a number of web services to run. There seems to be an issue with the following one:

🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.

🔗 Related URL

Parsing MDN data...
Parsing...

If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.

[annevk]

@alice raises an interesting question at WICG/webcomponents#762 (comment) which I also mentioned at #4607 (comment). How does :focus-visible fit into all this?

[tkent-google]

@domenic @annevk Do you have any comments on this PR?

[domenic]

I pushed some editorial tweaks.

The one thing I wonder is whether the normative impacts of an autonomous custom element's focus behavior should show up elsewhere in the spec. Maybe the bulleted list "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area ? And we might want to add a sentence near https://html.spec.whatwg.org/#click-focusable, perhaps after the two bullet points saying something like

For focusable areas that are autonomous custom elements, user agents should consider the element's focus behavior in determining whether the element is click focusable or sequentially focusable.

But, maybe this is all redundant with the sentence you added in https://html.spec.whatwg.org/#tabindex-value. In general the "If the value is null" section there is kind of confusing when compared with the "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area, hmm.

Thoughts welcome. (Perhaps from @rakina to as our focus spec expert.)

[rakina]

The one thing I wonder is whether the normative impacts of an autonomous custom element's focus behavior should show up elsewhere in the spec. Maybe the bulleted list "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area ? And we might want to add a sentence near https://html.spec.whatwg.org/#click-focusable, perhaps after the two bullet points saying something like

For focusable areas that are autonomous custom elements, user agents should consider the element's focus behavior in determining whether the element is click focusable or sequentially focusable.

But, maybe this is all redundant with the sentence you added in https://html.spec.whatwg.org/#tabindex-value. In general the "If the value is null" section there is kind of confusing when compared with the "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area, hmm.

I agree with adding another explanation for sequential & click focusability.
For the focusable area definition, I think we should add more after the "or the element is determined by the user agent to be focusable" to specifically call out the custom elements, or maybe specifically refer to the section in the tabindex value or even move it? (It was awkward for that section to be in the "tabindex value" part to begin with, should've moved it when the great focus spec rewrite happened :D)

[tkent-google]

Thank you for the comments.
I think my initial change had minimum necessary changes. However it was not so helpful.

The one thing I wonder is whether the normative impacts of an autonomous custom element's focus behavior should show up elsewhere in the spec. Maybe the bulleted list "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area ? And we might want to add a sentence near https://html.spec.whatwg.org/#click-focusable, perhaps after the two bullet points saying something like

For focusable areas that are autonomous custom elements, user agents should consider the element's focus behavior in determining whether the element is click focusable or sequentially focusable.

That's a good idea. Done.

But, maybe this is all redundant with the sentence you added in https://html.spec.whatwg.org/#tabindex-value. In general the "If the value is null" section there is kind of confusing when compared with the "Elements that meet all the following criteria" in https://html.spec.whatwg.org/#focusable-area, hmm.

I agree with adding another explanation for sequential & click focusability.
For the focusable area definition, I think we should add more after the "or the element is determined by the user agent to be focusable" to specifically call out the custom elements, or maybe specifically refer to the section in the tabindex value or even move it? (It was awkward for that section to be in the "tabindex value" part to begin with, should've moved it when the great focus spec rewrite happened :D)

I added one sentence to the table in order to link to null tabindex value. What do you think?

[domenic]

This looks great to me. /cc @whatwg/components to get broader input / multi-implementer interest.

[rakina]

lgtm

[tkent-google]

WPT PR: web-platform-tests/wpt#21063

[annevk]

Per https://whatwg.org/style-guide#tone I don't think we should use this name. Probably best discussed at WICG/webcomponents#762 (comment).