[whatwg] oninput event

[Ric Hardacre]

Christian Schmidt wrote:
> Quote from the current working draft (10 January 2006) 
> <http://whatwg.org/specs/web-forms/current-work/#the-change>:
>> UAs may delay firing the input event if the data entry is rapid.
>> Authors must not rely on this event firing once for each key press,
>> mouse input, or similar.
> I'm not sure what the intention is here.
> 
> I assume "key press, mouse input, or similar" refers to whenever the 
> control's value attribute changes, i.e. not key presses on arrow keys etc.
> 
> UAs may delay firing the event, but are they allowed skip it?
> 
> If UAs are NOT allowed to skip events, what is the purpose of delaying 
> them? And what exactly does delaying mean (e.g. what is the value of the 
> control's value attribute when the event eventually occurs)?
> 
> If UAs ARE allowed to skip events, I think it is a reasonable 
> requirement that the last event per control in a series of inputs is not 
> skipped, so that e.g. oninput="output.value=value" will always make the 
> output control be in sync shortly after the last key press (but not 
> necessarily while the user is typing rapidly).
> 

yes that's exactly the use i can foresee, i have this problem in an app 
I'm working on currently, we can either use onChange or onKeyPress to 
activate the totalizing function for a series of quantity and length 
boxes. (e.g. 12 at 4 meters, 8 at 3 meters, the total being the total 
metreage). neither event is entirely satisfactory, onChange only happens 
when the text box looses focus (which is not the usual behavior in 
standard windows apps and has been brought up in client consultation ass 
"odd") and onkeypress would be overkill IMO and would also yield 
intermediate invalid results. e.g. if an input is changed from 8 to 12 
the initial "1" of 12 would cause the total to go out of whack.

so a good implementation of onInput would occur after onKeyPress and 
before onChanged and would be sensitive to the user's computer's 
typematic delay.

ric