open-ui
open-ui copied to clipboard
openui
[select] keyboard behavior
We previously discussed standardized keyboard behavior for select in these issues:
- https://github.com/openui/open-ui/issues/386
- https://github.com/openui/open-ui/issues/433
However, since then we have switched from creating a new element to using a CSS property to opt in to the new thing. In addition, @annevk gave feedback that the select element should respect platform conventions instead of having standardized keyboard behavior (correct me if I'm wrong).
During the call earlier today, @scottaohara expressed concern about changing keyboard behavior on a CSS property.
With this in mind, should we just not change the keyboard behavior for customizable select? Caveat that we are still going to not do selection-follows-focus anywhere in the new mode.
It would be nice if there was a way to opt into standardised behaviour. Perhaps a new attribute for select? A big part of this standardisation work (imo) is to achieve consistency across platforms and it would be a shame to lose that.
selection following focus is the behavior for current selects on windows. so that was part of my concern - before when this was going to be a new element there seemed an opportunity to diverge from the current behavior (and actually align more with how macos selects work). but now this all being part of the select element, it does seem strange now that uncustomized it'd work one way, and customized it'd work another. i dont know how you could not change behavior, but also have selection not follow focus, since that's changing the behavior.
as mentioned, i know that there's a good number of people which would rather selection not follow focus, myself included... it just seems important to re-discuss this point since the decision was made under the assumption this would be a new element and behavior could arguably be different due to that.
Generally our opinion is that form controls should follow platform conventions as far as end user interactions go. While you can of course completely subvert this through script, I'm not sure we'd want to encourage it be making it standardized in some fashion.
Perhaps there are particular end user interactions that have an issue of sort though and those might warrant further investigation to see if they can be improved in some manner. But I suspect we'd want to improve them in a holistic fashion and not isolated to appearance: base controls.
cc @pxlcoder @rniwa
The behavior which I've implemented in the prototype which stands to change based on this discussion:
- What the arrow keys do when the listbox is closed. In appearance:auto
<select>on windows this changes the selected option without opening the listbox, and on mac i think up and down open the listbox but left and right don't. - What the enter key does when the listbox is closed. In appearance:auto
<select>on windows this opens the listbox, and I think on mac it submits the form instead of opening the listbox.
I think that everything else can stay the same as I've already implemented.
I have a keyboard behavior question on the customized <select>, now that it's no longer <selectmenu> --
Will focus events fire and document.activeElement now change as the user navigates through customized options in <select>? That seems perhaps necessary if we allow authors to add nested interactive controls to options; otherwise, I'm not sure how it would be possible to script click handlers & event targets.
On the other hand, having focus changes and document.activeElement updates while the <select> is still focused and open would be a huge and potentially breaking change. I know the code I currently work on has logic in place based on focus/blur handlers on <select>, and I've written similar code quite a bit in the past. Having the <select> blur and an element within it receive focus could very easily break a lot of that code. For dialogs and other elements that handle focus and contain multiple focusable items we do element.contains(document.activeElement) checks, but until now that hasn't been needed for <select>.
Has this already been discussed/is there a solution to it, or am I misunderstanding the planned behavior?
Will focus events fire and document.activeElement now change as the user navigates through customized options in
<select>? That seems perhaps necessary if we allow authors to add nested interactive controls to options; otherwise, I'm not sure how it would be possible to script click handlers & event targets.
Yes. If we kept the main select element focused then keyboard behavior would not work at all in the popover since we are making it work like regular web content.
On the other hand, having focus changes and
document.activeElementupdates while the<select>is still focused and open would be a huge and potentially breaking change. I know the code I currently work on has logic in place based on focus/blur handlers on<select>, and I've written similar code quite a bit in the past. Having the<select>blur and an element within it receive focus could very easily break a lot of that code. For dialogs and other elements that handle focus and contain multiple focusable items we doelement.contains(document.activeElement)checks, but until now that hasn't been needed for<select>.
I think that sites will have to fix this if they opt in to customizable select.
Has this already been discussed/is there a solution to it, or am I misunderstanding the planned behavior?
As you mentioned, switching to element.contains(document.activeElement) sounds like a good workaround.
Proposed resolution:
- Don't spec keyboard behavior in HTML because the requirement to follow platform conventions precludes this and because HTML doesn't currently mandate this kind of thing.
- Make base-select keyboard behavior in chromium try to match appearance:auto select when appropriate:
- Change the prototype's keyboard behavior for what the arrow keys do when the listbox is closed as per this: https://github.com/openui/open-ui/issues/1087#issuecomment-2338388584
I think my main worry is that as a library author, I do not really have insight into whether a downstream author has opted in to the customized select or not, since it's using the same tag name :/
I think my main worry is that as a library author, I do not really have insight into whether a downstream author has opted in to the customized select or not, since it's using the same tag name :/
You can still use the element.contains(document.activeElement) fix and have it worth for both cases though, right?
Going forward, yup, But in the spirit of "don't break the web", I just could see this breaking existing logic. Using the library I work on as a specific example, it's also quite a bit more complicated than checking element.contains -- there's logic scattered all across both the library and downstream usage around keyboard handling like tab or enter/space in addition to focus/blur. We also have higher-level focus management logic that has tag-specific handling that exists in a separate library.
It's not that there isn't a way to script around it -- there definitely is. It's more an issue that changing this now would likely break script in a variety of different places, probably in a lot more than I can even think of right now. And unlike library updates, we can't pin an HTML dependency version until we've adequately tested the update 😅.
The Open UI Community Group just discussed [select] keyboard behavior.
The full IRC log of that discussion
<bkardell_> jarhar: a year and a half ago we had meetings where we discussed keyboard behaviors for select lists. Since then we moved away from creating a new element to using existing <select> - now there is a question about whether the keyboard should work differently whether it is custom or not, and also talking to annevk he pointed out<gregwhitworth> q+
<bkardell_> jarhar: that they should follow platform conventions. I think after all of this I think we should rethink the keyboard behavior stuff and keep it simple and focus it on a few core things
<bkardell_> gregwhitworth: I disagree. A lot.
<bkardell_> gregwhitworth: So much
<gregwhitworth> ack gregwhitworth
<bkardell_> sarah: I think I agree with you greg that it is not worth following platform conventions, many of them are bad
<bkardell_> gregwhitworth: ok let's take this back to the task force
<bkardell_> masonf: for people with strong opinions, I bet this is based on a lot of experience and reasons and data -- I think it would be great if we can bring as much of that as possible to TPAC
<bkardell_> scotto: I kind of agree with both people. I do not agree it's the best keyboard ui for selects, but I was also the one that brought up the fact that they could work differently if customized vs uncustomized
<bkardell_> masonf: can I make the meeting run over time?
<bkardell_> s/can I make the meeting run over time?/....
<bkardell_> :)
<bkardell_> Sarah: we have a polyfill of what we think browsers should do, sort of - it has element specific targeting... we have a set of logic about a select and about something else.
<bkardell_> sarah: there's logic inside our select component too, but just focus handling, keyboard handling scattered all over the place - and if that all changes because someone added an option in a select somewhere it will be bad
<gregwhitworth> Zakim, end meeting
When ::picker(select) is open, we need to disable page scrolling when the Up and Down arrow keys(or Home, End keys etc.) are pressed.
https://github.com/user-attachments/assets/0c074f88-ad9d-4d47-ab81-c2a09e9b18f5
So I have a question about this? If "Caveat that we are still going to not do selection-follows-focus anywhere in the new mode." is true (which I really hope it is), how does that decision play into the decision about honouring platform conventions? If we can choose to ignore them in some places why can't we do that everywhere?
I guess this is more of a philosphical question than a technical one though.
So I have a question about this? If "Caveat that we are still going to not do selection-follows-focus anywhere in the new mode." is true (which I really hope it is), how does that decision play into the decision about honouring platform conventions? If we can choose to ignore them in some places why can't we do that everywhere?
I guess this is more of a philosphical question than a technical one though.
This is a good point, and yeah I don't personally care about following platform conventions. It was just the point that Anne brought up for not wanting to standardize keyboard behavior, which lead me to not want to try standardizing it, which lead to these discussions about reconsidering.
This is a good point, and yeah I don't personally care about following platform conventions. It was just the point that Anne brought up for not wanting to standardize keyboard behavior, which lead me to not want to try standardizing it, which lead to these discussions about reconsidering.
I won't be able to attend the call but my general stance is that if someone is opting into this behavior they're wanting interoperable extensibility, styles and behaviors. However, this one is one that doesn't HAVE to be included in V1 of select. If we did something akin to what we did for CSS accent-color where we denote key principles that user agents must account for then we can leave it to platform conventions for now and wait for feedback on how pressing of an issue this is. I envision people wanting alignment on whether the arrow down key cycles back to the first option or it doesn't, etc. That said, this is a hypothesis and to specify all of that will not be trivial and adding this in later should be viable.
Related to https://github.com/openui/open-ui/issues/1087#issuecomment-2381094286 The difference between the new select size=1 and the old select size=1 is that the new one has the popup living in the same process, so the events on the popup are visible to the document. That doesn't happen with the old select, since there the popup is in practice in some other process (at least in the most common browsers). Starting to get key events targeted to the popup is quite a new behavior, and at least some of that should be specified, possibly in a way which allows some differences between platforms.
That's a good point that I hadn't considered yet. I suspect we'll need to define some aspects of the events, such as what happens when you call preventDefault(), their relative order, etc. Perhaps this can be done by sort of abstractly defining what operations are expected to be available (opening the dropdown, cycling through the options) and then defining which events get fired when you initiate one and what happens in response to those events, if anything.
I suspect we cannot cover all operations as some platforms might allow for operations that other platforms don't, but the most common ones I would expect to be available everywhere, even if they are perhaps triggered in different ways.
I created an HTML issue about the recent discussion: https://github.com/whatwg/html/issues/10762