This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html Section: http://www.whatwg.org/specs/web-apps/current-work/#common-event-behaviors Comment: "User agents may wait for a suitable break in the user's interaction before queuing the task; for example, a user agent could wait for the user to have not hit a key for 100ms, so as to only fire the event when the user pauses, instead of continuously for each keystroke." Does any browser actually do this? If not, it should be removed, because it's misleading. Boris thinks he's seen pages that would break if a browser did that: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-November/028959.html Posted from: 68.175.61.233 by AryehGregor+whatwgspec@gmail.com
I'm not sure there are enough pages using the input event on form controls yet to know for sure. However, WebKit's legacy search event for <input type=search> does have the kind of hysteresis described here. Such hysteresis is a good idea if the Web page is going to show any UI (like a JS-updated completion UI) because you don't want it to thrash if the user types quickly.
But it's easy to emulate the hysteresis in a predictable fashion if the UA provides one input event per keystroke, while if it doesn't, there's no convenient way to do without it if you really do want to process each character. Even if you want this kind of batching, you probably want to control the exact parameters of how often you act on events, and that's not possible in the model the spec describes.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: There's no difference between what the spec describes and what a page would experience if the user was using an autocompletion IME (as, e.g., on a phone) or was pasting complete words, or using other mechanisms to enter multiple characters at once. So any page that breaks for this is already broken.
Maybe, but the fact still remains that the behavior described in the spec is not actually implemented by any browser AFAICT, so it's still misleading. It would be more helpful to say that browsers should fire the event on every character if the user is inputting one character at a time, but may also fire one event for multiple characters as well (e.g., in the examples you just gave). It's true that a script that expects input events on every keypress is already broken, but there's a big difference between broken in edge cases like copy-paste and broken for users typing normally on a keyboard. It's entirely possible that there are many pages that rely on browsers not doing what the spec describes, even though occasionally it fails, and in that case any new browser would have to match existing browsers' behavior for compat. Thus it should be specced.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If there are pages that actually break if you implement what the spec says, then that changes matters. However, I haven't seen any evidence of this. Pages I looked at that exhibit oninput-like behaviour seem to use onkeypress, not oninput, since that's what's implemented more widely. (And the main page I'm thinking of fails to handle paste correctly, which is how I noticed that it was doing anything like this at all.) If we don't have a back-compat constraint, then the specced behaviour is significantly better than requiring UAs to fire oninput after every onkeypress, because it gives authors a way to do expensive "instant" computation in a way that doesn't waste CPU resources and in a way that doesn't require complicated manipulation of timers.
I'm not going to argue it, but I still disagree.
mass-moved component to LC1