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
