-
Notifications
You must be signed in to change notification settings - Fork 191
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
[select] keyboard behavior #1087
Comments
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 |
The behavior which I've implemented in the prototype which stands to change based on this discussion:
I think that everything else can stay the same as I've already implemented. |
I have a keyboard behavior question on the customized Will focus events fire and On the other hand, having focus changes and Has this already been discussed/is there a solution to it, or am I misunderstanding the planned behavior? |
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.
I think that sites will have to fix this if they opt in to customizable select.
As you mentioned, switching to element.contains(document.activeElement) sounds like a good workaround. |
Proposed resolution:
|
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 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 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 |
We previously discussed standardized keyboard behavior for select in these issues:
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.
The text was updated successfully, but these errors were encountered: