- From: Michael A. Puls II <shadow2531@gmail.com>
- Date: Tue, 02 Dec 2008 06:59:52 -0500
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: public-html@w3.org
On Tue, 02 Dec 2008 05:40:26 -0500, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 12 Nov 2008, Michael A. Puls II wrote: >> > > >> > > It is not 100% clear what "changes" means. Does it literally mean >> > > "to a *different* value"? >> > >> > I've tried to make the HTML5 version of this clearer, but let me know >> > if it's still vague. (I am aware of a few places in the spec that are >> > vague about what they mean by "change"; I plan to fix that.) >> >> I don't see what "change" means defined anywhere. But, the examples you >> added (see next part of reply) help. > > Yeah the meaning of "change" is an open issue I'll have to address. I've > noted it in the spec. O.K. >> On a side note though, for the change event, pressing del in an empty >> text field and blurring (or pressing ENTER) fires in some browsers and >> not in others. So, the meaning of "change" here is important too. (when >> you have time) > > Right, this will be defined when "changed" is defined. Cool. >> "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" >> >> So, with <http://shadow2531.com/js/jsuri.html>, if I type really fast, >> is the javascript: field going to be unupdated for a moment until I slow >> down my typing? If so, how choppy is it going to look? Is 100ms an ideal >> time, or is that just a guess? >> >> I'm also a little afraid by the "may" and 100ms only being an example. >> If this is left up to the implementation whether it delays or not and at >> how many milliseconds, we will probably see different behavior in >> different browsers. Would it be possible to spec that UAs must delay, >> how, and at how many milliseconds (or at least a known range) (perhaps >> after UA implementation feedback is given)? > > It seems like defining this level of detail is unhelpful since it will be > affected by things like CPU speed, which isn't under our control. O.K. >> 1. I do not see the oninput attribute defined anywhere. > > Yeah I am planning on going through and adding all the event handler > attributes at a later date when the events are more stable. O.K. cool. >> 2. Also, I'm unsure what controls support the input event (and >> oninput=""). I see a table that has some 'yes' for different types of >> <input> elements, but I don't see it specified for others. Is 'input' >> supposed to fire for all form controls unless specified otherwise? Or, >> are you trying to limit it to most types of <input> and just <textarea> >> (as in, not for <select>)? > > For <input>, see: > http://www.whatwg.org/specs/web-apps/current-work/#event-input-input > > I just added the same text to <textarea>, which I'd forgotten. > > It indeed doesn't apply to <select> right now. Opera is the only one that supports it on <select>. Opera supports it on checkboxes and radio buttons too. This is probably because WF2 basically talked about 'input' as a change on any form control. > Should it? Not sure. I know nothing that depends on it for <select> except for some test caases. -- Michael
Received on Tuesday, 2 December 2008 12:00:35 UTC