Re: [whatwg] oninput event
On Mon, 13 Feb 2006, 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 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. Yes. UAs may delay firing the event, but are they allowed skip it? The spec was unclear on this. I've tried to fix 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)? The idea is that if a user types hello very quickly, you'll only fire an event at the end of the o, rather than five times in one millisecond, but if he types hell then waits then types o, you'll fire two events, one after the second l and one after the o. This allows authors to easily implement incremental search UI. 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). Right. Thanks, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] oninput event
On Tue, 14 Feb 2006, Ric Hardacre wrote: 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. That's exactly teh intention, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] oninput event - pasting
http://whatwg.org/specs/web-forms/current-work/#the-change
this specification introduces the input event. This event is fired on
a control whenever the value of the control changes due to input from
the user
Does due to input from the user mean that *every*, *direct* action
the user *makes on the control* (that changes its value) causes the
event to fire?
Specifically, if I have this:
textarea oninput=alert('test')/textarea
, and right-click and paste into the textarea or ctrl+v into the
textarea to paste, or select and cut, should the event fire?
I can assume that, the event should fire no matter how the user
changes the value (just as long as it's done directly and not by
invoking a script that changes the value), but I'd like to know for
sure.
Thanks
--
burnout426
Re: [whatwg] oninput event - pasting
On Thu, 8 Jun 2006, Shadow2531 wrote:
http://whatwg.org/specs/web-forms/current-work/#the-change
this specification introduces the input event. This event is fired on
a control whenever the value of the control changes due to input from
the user
Does due to input from the user mean that *every*, *direct* action
the user *makes on the control* (that changes its value) causes the
event to fire?
Specifically, if I have this:
textarea oninput=alert('test')/textarea
, and right-click and paste into the textarea or ctrl+v into the
textarea to paste, or select and cut, should the event fire?
Yes.
Another part of the spec mentions that the UA may coallesce multiple
inputs into one input event, so e.g. if you type very fast it might not
fire one input event per character, it might fire one every few hundred
milliseconds instead.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] oninput event
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). Christian
Re: [whatwg] oninput event
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
