Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is indeed a good point. </p> <p><strong>But first: A way to avoid this</strong></p> <p>Set a focus handler onfocus save the value. Set a blur handler onblur compare current value with saved value, if value has changed trigger/dispatch/fire a 'comittedchange' event. -> Use commitedchange event instead of busted change event :-)</p> <p>Here are some thoughts. But first read the HTML5 specification for the <a href="http://www.w3.org/TR/html5/common-input-element-apis.html#event-input-change" rel="nofollow">change event</a>.</p> <p><strong>Now some history</strong></p> <p>The HTML4 specification had a different definition (if a value/checkednes changed and the elements is activated or unfocused the event occurs), which was a bad thing especially for checkboxes and radiobuttons (This is the reason why people are using the click and not the change event for those elements (or jQuery)). </p> <p><strong>The new HTML5 spec</strong></p> <p>The new spec combines the first definition and adds some extra called 'explicit commit action'. Actually I do not really understand what this means, but I'm sure, while a user presses the mouse on a spinbutton (type=number), this user hasn't done a commit action, he is still interacting with the form and still might do a input/change.</p> <p>Additionally HTML5 added the input event, to inform the developer "sooner" about some non final changes. For example to combine this with the datalist element and allow dynamic changes i.e. create a autosuggest.</p> <p><strong>The reality: browsers</strong></p> <p>In case of input types with spinbuttons (type number, time etc.). Opera and Chrome behave very similiar (interacting with spinbutton triggers input and change) and Safari trigger the change onblur. In case of a type=range all browsers are handling this equal. The change event and the input event is triggered all the time, while dragging the mouse. Fine, we have two different events with different specification and usecases, but they are doing the same thing in reality (Yeah).</p> <p><strong>The reality: developers</strong></p> <p>Well there are a lot of tutorials and scripts out there using the change event for type=range for use cases, which should take the input event instead, but as you know, developers are stupid and only read 1% of the specification.</p> <p><strong>End of story</strong></p> <p>The old definition was bad and made it useless. The new specification was improved, but isn't understandable, was mis-used and bad implemented... And now??? I think noone wants to break old bad HTML5 tutorial / script code.</p> <p>If you want this to change <a href="https://code.google.com/p/chromium/issues/detail?id=155747" rel="nofollow">be my hero</a>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload