Event for monitoring radio button changes

[LeaVerou]

Problem: There should be an event to reliably monitor changes on a single radio button. Currently, any available event fires only when the radio button is checked, nothing fires when it's unchecked. Instead, developers need to be aware of every other radio button in the group and monitor events on those too. This is neither easy, nor foolproof. Since radio button grouping is done both by name and by form association, most existing solutions fail in a number of cases, most notably when radios are associated with forms via the HTML5 form attribute. Furthermore, such monitoring is error-prone because radio buttons could be added dynamically to the page at any point.

Proposal: The input event could be a good candidate for this, since it's not currently interoperable anyway, so it's unlikely that developers are depending on it. Namely, Chrome and Edge never fire it on radio buttons, and Firefox fires it every time it fires the change event. Testcase: http://codepen.io/leaverou/pen/jBKbqN?editors=1010

[domenic]

This makes sense to me, including the idea of using the input event.

I can't load that CodePen (it gives me "error! it looks like you are logged out!" then is "Loading........" forever) so I transcribed it into an equivalent at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4978, for anyone else who has the same problem. That revealed that Safari Tech Preview also does not fire input on radio buttons.

@tkent-google, @rniwa / @cdumez, @travisleithead, does this sound like a reasonable thing for us to add to the spec? (The spec currently says that input should fire whenever change does, although none of your browsers do this yet. This would also fire it when the checkedness gets set to false by the clause at https://html.spec.whatwg.org/#radio-button-group starting "When any of the following phenomena occur".)

@smaug---- would Gecko be OK with adding this additional case to their input event implementation?

[tkent-google]

Sounds a reasonable platform addition, and changing input event is a nice idea.

[smaug----]

Doesn't sound very backwards compatible to fire it also for unchecked radio buttons. This would most probably break pages relying on the currently spec'ed behavior.

[domenic]

@smaug---- did Gecko encounter any such breakage when it started firing it for checked radio buttons, unlike every other browser?

[smaug----]

I'm not aware such issues, but also that doesn't tell anything about this case, assuming I understand the proposal that there would be two input events. One for the unchecked and one for the checked radio button. Conceptually firing input on unchecked radio button, which itself didn't get any input, sounds a bit wrong.

[domenic]

OK. I don't think we should assume it would be incompatible, given that only one browser fires such input events and didn't encounter any compatibility issues going from 0 -> 1.

I think conceptually it is a good idea to use input to signal changes to the control, like it is used for all other controls.

[Yay295]

I think what smaug is saying is that it doesn't make sense to fire an input event on an element that hasn't itself received input. However, if you instead think of it as "there was an input somewhere, and the value of this element was changed because of it", it does make some sense. The real problem is that radio buttons just don't act like any other input type, because when they're grouped together they act like a single element.

[LeaVerou]

@smaug---- as I mentioned, the input event is already incompatible across browsers for radios, so it's unlikely that web developers are depending on any particular behavior for it. Conceptually, I think it makes sense to fire it when the value changes due to user interaction, like what happens with all other controls. Whether the interaction happened on the current radio or not is irrelevant: it's value changed and that needs to be monitored. As a web developer myself, I was very surprised to realize that it didn't fire when the radio was unchecked. And @Yay295 is right: radio buttons are a special case of control, where they all behave like a single element. The whole point of the input event is to monitor value changes due to interaction on a higher level than what can be achieved with lower level events like e.g. keyup or click. And if developers need the current behavior, they can always use change. As it currently stands, input on radios is underutilized and useless in practice.

[smaug----]

I can easily see some script libraries having input event listeners for radio buttons, just because other input elements get input events too, and starting to fire multiple input events per one user action may then be surprising. That is why I'm worried about this change.

[LeaVerou]

1. There is still only 1 input event max per element.
2. When events fire more than expected they can always be throttled but not firing enough cannot be worked around.
3. Currently browsers fire 0 or 1 per interaction, not sure how that's different from 1 or 2.
4. input is an event that typically fires pretty often anyway, think of typing in a text box or dragging a slider. 1 vs 2 doesn't make that much of a difference when it fires dozens of times on other controls.

[smaug----]

I'm not strongly against this, but worried about web compatibility. I would assume this kind of change would need to be first some time in nightly channels before landing to release branches of browsers. (and even then we might see some issues when releasing the new behavior.)

[LeaVerou]

I would assume this kind of change would need to be first some time in nightly channels before landing to release branches of browsers.

Of course, like every other change to the Web platform…

[domenic]

Thanks, it's good to get more clarity on Gecko's concerns and hear that they can be mitigated by successfully shipping this in other browsers. As such I think this needs interest from one more engine besides Blink before we can change the spec. Usually @cdumez / @rniwa are pretty good about commenting, and we've only given them a day so far, so I remain hopeful :).

[LeaVerou]

One thing we need to discuss is: under this proposal, would all radios in the group receive an input event? If it's only the checked and unchecked radios, that is still not sufficient for monitoring value changes without being aware of the other radios in the group. E.g. if I have 4 radio buttons, A, B, C, D and I uncheck A by selecting D, the entire group's selected value has changed, but no event has fired on B and C.