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

On Mon, 29 Sep 2008, Michael A. Puls II wrote:
> 
> WebForms 2 specifies both the DOMControlValueChanged and input events.

In HTML5 I've dropped DOMControlValueChanged. I think it would be better 
for this event to be defined in the DOM Events, DOM Mutation Events, or 
ARIA specifications. I may readd it once we integrate ARIA and HTML5.


> "In addition, to address the need for even more immediate feedback 
> mechanisms, this specification introduces the input event. This event 
> must be fired on a control whenever the value of the control changes due 
> to input from the user, and is otherwise identical to the change event. 
> (For example, it bubbles, is not cancelable, and has no context 
> information.)"
> 
> 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.)


> Also, I think when the events are specified, examples like copy, paste, 
> undo, redo, clear, delete, cut, drag and drop, insert etc. should be 
> given as user actions that could change a controls value and fire the 
> events. Basically, it needs to be clear exactly what situations should 
> cause the events to fire.

I've tried to make this clear in the example in the spec.


> Also, "due to input from the user" is not very clear. If I click on a 
> form reset button (which doesn't involve scripting) and the reset 
> process changes a control's value, should the input event fire or only 
> DOMControlValueChanged? I personally think this qualifies as "input from 
> the user" (but doesn't work in any browser). However, if the input event 
> is specified to only fire from "user input directly on the control", 
> then the reset case would only fire DOMControlValueChanged. Also, if I 
> click on a button that causes a JS event to execute that modifies a 
> control's value, that's still user input, just not directly.  It needs 
> to be clear exactly what is user input and what is not as far as when 
> the event is fired.

I've tried to define this.


> "UAs may delay firing the input event if the data entry is rapid, 
> coalescing events for several pieces of rapid input into just one event. 
> Authors must not rely on this event firing once for each key press, 
> mouse input, or similar."
> 
> This doesn't make sense at all. If you can't count on the events
> firing exactly once for each change, the events are useless.

Why? What difference does it make if the user types "ab" quickly, or 
pastes the string "ab" as one action?


> I assume that was thrown (without even specifying how to do it so 
> browsers can do it the same) into the spec for performance reasons. 
> However, even now, with Opera firing 'input' twice for every change, 
> it's not a performance problem.

The idea is that if the input event does something like fire an XHR to get 
some prefilling data, there's no point doing that work if the user is 
typing quickly, since he won't be watching the results anyway.


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

Received on Wednesday, 12 November 2008 00:58:54 UTC