Re: [forms] Detailed review of the DOMControlValueChanged and 'input' events

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.


> 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.


> "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.


> 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.


> 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. Should it?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 2 December 2008 10:41:03 UTC