<selectmenu> input/change events and the value property

[dandclark]

I've been thinking about how the input and change events and the value property should work for <selectmenu>. The old <select> has the following behavior in Chromium:

• When the listbox is in the closed state, each press of the up/down arrow to switch to a new option fires the input and change events.
• When the listbox is in the open state, input and change events are not fired as the user uses up/down arrow to navigate the options. When the listbox closes because the user clicked an option or hit the Enter or Escape key, the input and change events are fired if an only if the new value is different from the value that the control had when the listbox was opened.
• When the listbox is in the open state, the value property does not change as the user arrow-keys through the options. value only updates as the listbox is closed.

In Firefox the behavior is the same except that when the listbox is in the open state, value changes as the user arrow-keys through the options.

Haven't had a chance to test in Safari yet.

I the closed <selectmenu> behavior should match the behavior for the current <select>.

For an open <selectmenu>, I'd like to consider a slight tweak. The behavior for <input type="text> is that the value changes as the user types, and input is fired for each character typed. Then change fires when the user tabs out of the control or hits Enter, if and only if the value of the control is different from when the user first started editing the input's value.

Analogous behavior for <selectmenu> would be the following:

• When the listbox is in the open state, input event (but not change) is fired as the user uses up/down arrow to navigate the options. When the listbox is closed because the user clicked an option or hit the Enter or Escape key, the change event is fired if and only if the new value is different from the value that the control had when the listbox was opened.
• When the listbox is in the open state, the value property does changes as the user arrow-keys through the options.

I think it could make sense to take this opportunity to align more closely to <input type="text"> in this way. On the other hand, the old behavior seems ok and it might be simplest to keep things aligned with the old <select>.

[dandclark]

I was using this page to test these behaviors: https://codepen.io/daniec/pen/eYGpdeZ

[css-meeting-bot]

The Open UI Community Group just discussed <selectmenu> input/change events and the value property.

The full IRC log of that discussion

<gregwhitworth> Topic: <selectmenu> input/change events and the value property
<gregwhitworth> github: https://github.com//issues/429
<andrico1234> dandclark: this is about input change firing on select and how it relates to value property. current behaviour in Chrome and FF is consistent between browsers, but doesn't make sense when thimnking events in context for other input ptypes
<andrico1234> dandclark: rthe way they work with popups in FF cand chrome, i open combox box and navigate with keys, when i click the list box, each even fires just ones, if the option had been change
<andrico1234> dandclark: this seems like reasonable behaviour, but one thing that's suspicious it its different from how it works with other input types. with text, each character i type i get an input event, then one change when i subnit, on blur or on submit. the input event is telling when a user has changed, the change event says the value being submitted is different than what's being before
<andrico1234> dandclark: analogous behaviour, if i open it, when i arrow key through ioptions, i should get input event when i move focus, when i close the list box i should get one change, if the one selected is not the one that was the previous value
<andrico1234> dandclark: if we consiuder new customisable select control, we can keep the behaviour from the old selec,t or bring behaviour more inline with how it works with other input types, confirm details how it looks like. do we keep with old behaviour, or go with new behaivour
<flackr> q+
<gregwhitworth> q+
<andrico1234> dandclark: we've spoken about this before, whether to stick with old interface, is it worth going with the new behaviour?
<andrico1234> q?
<andrico1234> ack flackr
<gregwhitworth> ack flackr
<scottohara_> q+
<andrico1234> flackr: i see trying to align input types makes a lot of sense. the actual select box is implemented outside of the browser ui. in mobile platforms you have OS specific popup on top. not interacting with application. if implemented in web page, event should fire on interaction like everything else
<andrico1234> gregwhitworth: i plus one you're suggestion , it makes sense. as you traverse events the value should adjust
<gregwhitworth> ack gregwhitworth
<andrico1234> gregwhitworth: we've never noticed the disparity before
<andrico1234> scottohara_: i don't have a strong opinion, i would advocate that a change made here is backported to standard selects. it would be weird having two components that are similar, but behave differently
<andrico1234> gregwhitworth: i don't see how we can do that with web compat
<andrico1234> scottohara_: that seems weird to me, i worry if we have new select that exposes a listbox, if it behaves differently from old versionm, it would pose problems for people
<andrico1234> gregwhitworth: if 5 years down the road, i expect current select to be legacy, so what should the correct behaviour be?
<andrico1234> scottohara_: i don't diasgree, but we have input type is image, which is ridiculous, like input submitted, there are more appropriate ones, but they're not deprecated or invalid.
<hdv> q+
<andrico1234> gregwhitworth: they won't become invalid or get deleted, this would be a brand new element
<andrico1234> gregwhitworth: let's take filtering in combobox, the input would have different events firing that the listbox won't have. if someone is using the new select menu, they'll be building their app using the new select menu entirely
<gregwhitworth> ack scottohara_
<andrico1234> una: we shouldn't let old implementations prevent us from thinking forward
<andrico1234> una: because old versions are broken, doesn't mean we should not implement new versions
<andrico1234> scottohara_: i agree, but wanted to raise a concern that there would be a divergence in behaviour
<gregwhitworth> q+
<andrico1234> hdv: i wanted to plus + 1, it would be different behaviour, but a different type of element. with select you can only pick one, but with select menu you can pick more than one element. it makes sense change evetn would do more, or fire more often
<gregwhitworth> ack hdv
<andrico1234> gregwhitworth: i want to raise a new issue, but acknolwedge scott's point. if we're building a new eleent, should in the spec, here's how it differs from the old element. leads into una's point of education
<andrico1234> gregwhitworth: should we acknolwedge this difference in the official specs?
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<flackr> https://jsbin.com/kuwofov/edit?html,js,output
<andrico1234> dandclark: selectmultiple fires input events instantly
<dandclark> Proposed resolution: <selectmenu> input/change/value behavior should diverge from <select> in the following way to more closely align with other <input> types: when the listbox is open, input events should fire as the user arrow-keys through options, and the value property updates to reflect the currently selected option. When the listbox closes, change fires if the currently selected option is different from the selected option when the
<dandclark> listbox was opened.
<andrico1234> dandclark: a couple things, i didmention the value property, which is related. it fits with the events. currently the value property, doesn't upated until i click enter, tied to change event. it would make sense to change at the same time
<andrico1234> gregwhitworth: does anyone have any objects to resolutions
<andrico1234> resolved: <selectmenu> input/change/value behavior should diverge from <select> in the following way to more closely align with other <input> types: when the listbox is open, input events should fire as the user arrow-keys through options, and the value property updates to reflect the currently selected option. When the listbox closes, change fires if the currently selected option is different from the selected option when the listbox w[CUT]
<andrico1234> bkardell_: how can we incorporate research into our work

[dandclark]

Closing this per resolution above.