Further selection refinements for collapsed selectlist

[scottaohara]

This is a follow on to #855

When reviewing this selectlist demo I noticed that while the behavior was changed to no longer have selection follow focus - and thus behave more similarly to macOS, that even the macOS-like behavior had one odd use case. When the selectlist is in the collapsed state, I can start typing characters and that will cause a selection change to the option that best matches the characters I typed. That automatic change does not occur when the listbox is rendered. This is, however, how the macOS select element behaves currently (though I can briefly pause and start typing new characters and the selected option will change to match that new set of characters - but the selectlist demo only seems to work once in this regard. If i want to start typing to change options, i have to move focus away from the selectlist button and then move focus back for typing to change the option once again.)

It seems to me that we should probably change this behavior for selectlist, as for one it already seems strange to me that this even happens with macOS's select element - since all other interactions with the button part open the listbox, rather than immediately change the selected option. But on Windows, where the behavior is shifting away from current expectations to align more with macOS - this is the only behavior that would remain as it does with the current select element - and it honestly feels like a bug / a missed behavioral change (e.g., start typing characters and that opens the listbox / moves to the matching option).

So, tldr; since it was previously resolved to not be so eager with selection for selectlist, i'd submit character typing when the selectlist's listbox is in the collapsed state, and having that autoselect an option / causing a change event, is a lingering eagerness that should be changed as well.

[josepharhar]

So we shouldn't do typeahead while the listbox is closed? Seems fine to me I guess. I suppose some people might like this behavior, but i shouldn't be too hard to also press the spacebar first to open the listbox right?

[mfreed7]

Would it be out of line for typeahead to both a) open the listbox, and b) start matching the typeahead? That would at least align expectations that events are fired as the selection is changed because there's an open picker.

[josepharhar]

Yeah I feel that we should do something since typeahead when the listbox is closed seems to work on all platforms for the existing <select> element

[css-meeting-bot]

The Open UI Community Group just discussed Further selection refinements for collapsed selectlist, and agreed to the following:

• RESOLVED: when doing typeahead when the listbox is closed, the listbox should open to show the newly selected option without firing a change event or committing the newly selected option

The full IRC log of that discussion

<jarhar> scotto_: the short version is that - i was testing the demo i think joey had made about selectlist and the selection no longer following focus
<jarhar> scotto_: noticed that interacting with it just wasnt getting the same behaviors i would have expected with typeahead
<jarhar> scotto_: macos and windows had variations with change event
<jarhar> scotto_: no idea what current progression of selectlist using select element impacts this
<jarhar> q+
<masonf> q+
<jarhar> scotto_: does that mean we have to stick in line, or can we deviate
<jarhar> scotto_: long story is - mason you had mentioned for typeahead can we just open the listbox so we can see the selection changing and doesnt cause a change event - thats fine, lets just do that
<jarhar> scotto_: and have windows and mac do the same thing
<masonf> jarhar: select vs selectlist, new thing is different and can have different behaviors
<masonf> jarhar: nuance, replace button and/or listbox. What happens if you just replace one?
<masonf> jarhar: will need to discuss this with implementers obviously.
<masonf> jarhar: typeahead should keep working with the listbox closed.
<masonf> ack jarhar
<jarhar> masonf: we should be free to treat the new thing as a new thing, the dev is opting into new behavior
<jarhar> masonf: very little spec on what the current select behavior is
<jarhar> masonf: we should be free to change the behavior of the new thing and do the right thing
<jarhar> masonf: if there are problems with the existing thing, we should not copy those
<jarhar> masonf: typeahead should work
<jarhar> masonf: issue with typeahead when closed is confusing, seems good to open the listbox when doing typeahead
<jarhar> masonf: also cleans up the event structure because i can fire input events but not change events in that case
<jarhar> masonf: this will come up again in whatwg. lets pretend that we have the freedom to do the right thing and lets figure out what that is
<jarhar> scotto_: imo it is to do what we've been discussing to have the popup show and not fire the change event
<jarhar> scotto_: that is consistently something that people get failed for when doing ax audits
<jarhar> scotto_: theyre like i can click on the thing i want, for the combobox i press the down arrow and why did my page just change
<jarhar> proposed resolution: when doing typeahead when the listbox is closed, the listbox should open to show the newly selected option without firing a change event or committing the newly selected option
<dandclark> +1, sounds like good reasons to do this.
<keithamus> +1
<lukew> +1
<Zander> +1
<scotto_> +1
<jarhar> RESOLVED: when doing typeahead when the listbox is closed, the listbox should open to show the newly selected option without firing a change event or committing the newly selected option
<jarhar> github-bot
<jarhar> zakim, end meeting

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.