[select] keyboard behavior

[josepharhar]

We previously discussed standardized keyboard behavior for select in these issues:

• [select] Clarify use of Enter/Space keys for opening/closing listbox #386
• Arrow key up/down on closed <selectmenu> #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.

[lukewarlow]

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.

[scottaohara]

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.

[annevk]

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

[josepharhar]

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.

[smhigley]

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?

[josepharhar]

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.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>.

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.

[josepharhar]

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: [select] keyboard behavior #1087 (comment)

[smhigley]

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 :/

[josepharhar]

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?

[smhigley]

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 😅.

[css-meeting-bot]

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

[yisibl]

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.

output.mp4