-
Notifications
You must be signed in to change notification settings - Fork 192
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
[focusgroup] Interactions with native elements (that have focusgroup-like behavior built-in) #995
Labels
Comments
travisleithead
added
agenda+
Use this label if you'd like the topic to be added to the meeting agenda
focusgroup
labels
Feb 21, 2024
travisleithead
added
focusgroup
and removed
focusgroup
agenda+
Use this label if you'd like the topic to be added to the meeting agenda
labels
Mar 5, 2024
The Open UI Community Group just discussed
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). |
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.The text was updated successfully, but these errors were encountered: