<selectmenu> eagerly makes selections

[argyleink]

I believe the selection should be made when the option is chosen, not while it's just being perused:

1. would prevent the width jank as shown in the video
2. would prevent the oninput event from firing for each keyboard navigation
3. would align it's behavior to that of a mouse

see video

codepen for the above video

[josepharhar]

@scottaohara do you know what the arrow key behavior should be while the listbox is open? I think that we discussed arrow key behavior while the listbox is closed but not while its open here: #433

[argyleink]

iirc, windows works as the prototype shows but no other OS does? I've written JS to disable it so all browsers work the same when perusing select menu options from keyboard. Like on this site, if change fired while just navigating the options, it'd change the url and the user would lose their place and be surprised about the change. a screenreader doesnt have the issue, they've got the virtual cursor iirc.

[scottaohara]

if someone invokes the combobox's listbox popup, then the change event should only fire when a purposeful selection/closure of the listbox has been made. Windows does change the current option shown in the combobox trigger when cycling through focused options, but the change doesn't occur until the user purposefully makes the change. On macOS, chosen option in the trigger doesn't change until the purposeful selectin has been made. IMO this is the better option.

Some points of clarity though, regardless of what choice is made, some 'jankiness' would still occur if the triggering element adjusted in size based on the current value. IMO that looks broken and maybe selectmenu should behave more like the select element here, and have its min-width based on the length of its longest option - allowing people to overwrite this if they see fit, but avoiding some of this awkward resizing behavior by default.

Re: the commentary of how a screen reader would not have the 'change' issue - that's not really true, as this component would generally pop someone into forms mode - which is the expected way to interact with such a control. using virtual pc cursor would not be how someone would normally interact with the contents of the listbox popup, and is actually not even possible to be interacted with in this way with the native select element.

Final FYI, the UX of the select element on this site's is rather broken on Windows, as I can hear this is an unnamed combobox, and i can use up/down arrow keys to change the selection without opening the popup - but because the activation behavior has been suppressed, while i can hear myself changing the selected option, nothing happens. i have to then hit enter to attempt to select, but this then opens the popup instead, and now i have to re-activate the item i was already attempting to activate. a popup of a list of links would have been more expected here is all.

[css-meeting-bot]

The Open UI Community Group just discussed <selectmenu> eagerly makes selections, and agreed to the following:

• RESOLVED: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Visiting options does *not* update the "selected" or "previewed" value.

The full IRC log of that discussion

<gregwhitworth> topic: <selectmenu> eagerly makes selections
<gregwhitworth> github: https://github.com//issues/742
<jarhar> argyle: ive noticed in the past while using select elements
<jarhar> argyle: on windows, as you arrow key through it, it emits the change events. annoying because user hasnt made a selection yet, difference between perusing options and confirming your choice
<jarhar> argyle: id like to see some interop on this. if theres a good reason for eager choices, then that can be fine
<masonf> q?
<Brecht_DR> q+
<masonf> q+
<gregwhitworth> ack Brecht_DR
<gregwhitworth> q+
<sarah_higley> q+
<gregwhitworth> ack gregwhitworth
<jarhar> brecht: i made a selector in the past that would choose some options that also had an svg element, which adds some extra difficulty because you want to use script to put svg in currently selected state
<jarhar> brecht: it would become more complicated to update it while selecting
<jarhar> brecht: i would love to see the value change when you actually make your option
<jarhar> argyle: i wonder if theres a way to distinguish onchange and oninput, then you would get the best of both worlds
<jarhar> argyle: oninput would be when selecting with keyboard
<jarhar> gregw: each option would get focused as theyre perusing the options
<JonathanNeal> What argyle just described is what I would have expected. It would align with my experience with a text input. Mason is saying all of this, never mind. :P
<jarhar> masonf: event wise, it should just be what adam said. when moving along the options, you just get input events, and when you accept that value, you get a change event
<jarhar> masonf: that should be how its implemented, if not its a bug
<gregwhitworth> ack masonf
<jarhar> masonf: harder one, should the preview change as you select. i would rather go whatever way is easier to override
<jarhar> masonf: im not sure either option is easy to undo
<jarhar> masonf: i wonder if we need an attribute for that
<jarhar> argyle: like you put an eager attribute on it or something
<gregwhitworth> q+
<jarhar> argyle: ive used select elements that use big layout or navigation changes. that is very distruptive for keyboard users
<gregwhitworth> ack sarah_higley
<jarhar> sarah: i also have a preference with some reasons for not changing the value until the user has committed it
<jarhar> sarah: the escape behavior also differs on macos vs windows. on windows where the displayed text changes, when you press escape it does not go back to the previous value. it commits the value that you have arrowed to
<jarhar> sarah: on macos, where it doesnt change the displayed value, it does not change the value when you press escape
<jarhar> sarah: the windows one i always found weird, it seemed weird, it does not match combobox on native where escape clears the value or goes back to previous
<masonf> +1 - ESC should "escape" you from your choices and go back.
<scotto> q+
<jarhar> sarah: windows select behavior has always seemed weird and doesnt match anything else. id love if selectmenu does not do this
<jarhar> sarah: firing input on each selection would be different. right now they fire when you actually choose an option
<jarhar> masonf: so on the existing select, you get both input and change only once and only when you commit?
<jarhar> sarah: yes
<jarhar> sarah: because you can arrow through while closed, that fires input
<jarhar> gregw: +1 that windows behavior is weird
<jarhar> gregw: i agree with escape as well, it should be like an undo, just keep it as whatever it was before
<JonathanNeal> If the web select menu is not matching other controls in Windows apps, and if it does not match other web inputs, then it seems like a compelling case to normalize the behavior.
<jarhar> gregw: i think it would be great to figure out proposed resolutions for both
<sarah_higley> just double checked, the JS events for input and change do not fire on Windows when you arrow through the open <select>'s options. They both fire when the select closes
<jarhar> gregw: oninput, i dont have a strong opposition to adding it in, for selectmenu specifically if we are already transferring focus thats already handled
<jarhar> gregw: that would be a separate issue of how oninput should work for selectmenu
<jarhar> gregw: no opposition, but technically a separate issue
<gregwhitworth> ack gregwhitworth
<jarhar> scotto: i dont have much else to add, i had also forgotton about the decision to not allow change of selection while selectmenu is collapsed, kind of a moot point if we move over to always expands
<gregwhitworth> ack scotto
<jarhar> scotto: should we consider a default min width style for the selectmenu for jank when changing option
<gregwhitworth> q+
<argyle> q+
<jarhar> scotto: for the select element now, you can put it in a form and it takes on the width of the longest string
<JonathanNeal> My tiny opinion has been that input/change events kind of map to input/changes to files; where oninput is me editing a file, and onchange is me saving a file.
<jarhar> scotto: layout will adjust based on current value of the select element. i dont see any reason why we wouldnt allow authors to override that behavior. would make more consistent ui layout without needing an author saying that it shoud constantly change on me
<jarhar> scotto: for many forms i could see it matching the current select's width rather than having developers go in and say no i dont want this to change
<gregwhitworth> ack dbaron
<jarhar> dbaron: when mason made the comment about escape, my intuitive reaction was weird, id expect escape to keep the value that you currently have selected. i find the windows behavior intuitive, it might have a long experience of using the web on windows
<jarhar> masonf: to clarify when you mean the currently selected value, whatever you have hovered with the mouse?
<jarhar> dbaron: i was thinking with keyboard, my intuition is that youd get that option
<bkardell_> +1 to disagree with dbaron's sense of intuitive here :)
<jarhar> masonf: so youd expect escape and enter to do the same thing?
<jarhar> dbaron: id be worried about using enter because it could submit the form
<jarhar> bkardell: i agree with everybody elese
<jarhar> gregw: i dont know if we have user agent styles, and thats where that discussion about width would come in
<gregwhitworth> q?
<dbaron> s/the web on windows/the web on windows and linux/
<gregwhitworth> ack gregwhitworth
<jarhar> masonf: i dont think that can be done with css, its about the width of the text, would require some browser magic to do that
<jarhar> gregw: i dont want to conflate this issue with that, we should open another issue about that
<jarhar> masonf: i agree that deserves its own issue
<gregwhitworth> ack argyle
<jarhar> argyle: i have a strong opionon about that. i said jank, but this is also a feature that you literally cannot do with the current select, that its always the same length
<jarhar> argyle: if you want to put it inline with text, it ruins the flow
<jarhar> argyle: if you made it the width of the text it would make it better since its no the width of the max thing. i would like it to be overrideable
<jarhar> argyle: even though i said its jank, i really like it and it allows a bunch of other demos
<JonathanNeal> If select fits the selected content, what happens when you’re picking a different option? Does the selection option get longer?
<masonf> q?
<masonf> Proposed resolution: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Think further about whether the currently visited option gets "previewed" in the selected-value element, and whether there needs to be an opt-out/in, or whether that behavior is easy to override.
<jarhar> gregw: can you open a separate issue?
<JonathanNeal> +1 to the proposed resolution
<jarhar> gregw: default user agent styles would be impacted by this
<jarhar> argyle: i have some demos that ill share
<scotto> +1 new issue for one person's jank being another person's.... :)
<JonathanNeal> thanks, argyle! Those are great points, and I will check those demos out.
<sarah_higley> small update -- I currently can't find any select controls on Windows that function like <select> in the browser -- both editable and select-only comboboxes, old and new, revert on escape
<JonathanNeal> I agree that “previewing” could be discussed separately.
<argyle> hi jon!
<sarah_higley> +1 to the proposed resolution
<Brecht_DR> +1 on this
<masonf> Proposed resolution: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Visiting options does *not* update the "previewed value".
<JonathanNeal> Oh sweet, I can get behind that, too. +1
<una> +1
<jarhar> gregw: should we say selected value since thats the part thats being updated?
<jarhar> masonf: i dont know if script on the page can see the value being updated
<masonf> Proposed resolution: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Visiting options does *not* update the "selected value".
<jarhar> gregw: there is no previewed value, theres only the selected value
<dbaron> the "selected value" *or* the "previewed value" ?
<jarhar> gregw: can you define use case with preview and selected value
<masonf> Proposed resolution: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Visiting options does *not* update the "selected" or "previewed" value.
<jarhar> masonf: as you move along the options, the text in the selected value changes
<jarhar> gregw: that is the selected value part thats being changed
<JonathanNeal> I’m giving +1s to all of these things.
<argyle> lgtm
<JonathanNeal> You get a plus one. You get a plus one.
<jarhar> gregw: for autofill there is a previewed value
<jarhar> masonf: cant be standardized, but browsers have a way of showing a previewed value
<jarhar> una: placeholder wouldnt update
<jarhar> gregw: im not going to object to this
<masonf> RESOLVED: selectmenu should fire `input` as options are visited with the mouse or keyboard, and `change` is fired only when an option is selected. Escape acts as "undo" and does not fire a `change` event. Visiting options does *not* update the "selected" or "previewed" value.