[focusgroup] Interactions with native elements (that have focusgroup-like behavior built-in)

[travisleithead]

Putting some thoughts down here for discussion. This is currently an open question in the spec.
(This issue was split off #990)

How to treat native elements that already have a focusgroup-like behavior? This could go various ways. One way is to treat elements like <select> as if they declare their own internal focusgroup (which I guess they do, sort of), and to have author-defined focusgroups not apply in those cases.

Another direction is to try to blend the behavior or allow author-supplied focusgroups to customize (overwrite?) the pre-existing focusgroup-like behavior of native elements (like <select>). I can see this being helpful, for example, to apply a direction constraint (horizontal or vertical) to the native control so that the keyboard interaction of the native element fits better within an existing containing focusgroup (or to change the wrapping behavior).

With exclusive accordions and existing named radio buttons, there can be focusgroup-like behavior applied without a containing element. It would require a new method of attaching focusgroups to allow an author-defined focusgroup to override the arrow-key behavior of either one of these parent-less grouped controls. (Perhaps something like focusgroupfor=name_of_radio_or_exclusive_accordion to bind it up.)

And with all that, there are still controls like input type=text, input type=number, input type=range that trap arrow key behavior and should probably not be affected by focusgroups.

[css-meeting-bot]

The Open UI Community Group just discussed [focusgroup] Interactions with native elements (that have focusgroup-like behavior built-in), and agreed to the following:

• RESOLUTION: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements).
• RESOLVED: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements).

The full IRC log of that discussion

<Penny> Comment
<masonf> scribenick: Penny
<Penny> scribenick: Penny
<argyle> test home/end/cmd+arrow behavior in a focusable scroller area in this prototype https://codepen.io/argyleink/pen/wvZMMZv
<philippg> q-
<Penny> @travis: What do we do when author put focus groups or attempt to put focus groups on native elements that bindings to page up, page down, or others that are conflicting such as textarea, radiobuttons.
<masonf> q+
<scotto_> q+
<Penny> @travis: Also How do we even attach a focus group to a group of radiobuttons since there's no parent element?
<keithamus> q+
<dandclark> q+
<Penny> @masonf: seems like the thing to do is to have a list of elements that are not allowed
<Penny> @masonf: Ones that have no meaningful use case, disallow
<masonf> ack mason
<masonf> ack scott
<masonf> q+
<masonf> ack keith
<Penny> @scotto_: Maybe we can now more narrowly define behavior for these things?
<Penny> @keithamus: There is an upcoming spec change to allow a focusgroup on an element to be inclusive of the element, it's exclusive but the change would make it inclusive.
<masonf> ack dan
<dandclark> https://dom.spec.whatwg.org/#valid-shadow-host-name
<Penny> @dandclark: Question of whether this should be an allow list or block list. Start with a pre-existing list to be proposed
<bkardell_> the sanitizer api has a list of "funky elements" https://wicg.github.io/sanitizer-api/#handle-funky-elements :-p
<Penny> @masonf: allow list seems the better approach, we can enumerate a list on the issue
<masonf> ack mason
<scotto_> potential allow list elements - article, section, nav, aside, hgroup, header, footer, address, ol, ul, menu dl, search, div, custom elements, table, fieldset, li, dd
<Travis> PROPOSED RESOLUTION: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements.
<bkardell_> oh I wasn't proposing that list
<Travis> PROPOSED RESOLUTION: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements).
<Travis> RESOLUTION: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements).
<Travis> RESOLVED: propose a list of allowed elements that may have the focusgroup attribute (based on preexisting lists such as valid shadow hosts/ sanitizer funky elements).