Open josepharhar opened 1 week ago
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:
<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.<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.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 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:
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
.
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.