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

On Tue, 11 Nov 2008 19:58:18 -0500, Ian Hickson <ian@hixie.ch> wrote:

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


O.K.


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


I don't see what "change" means defined anywhere. But, the examples you  
added (see next part of reply) help.


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)


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


"Examples of a user changing the element's value would include the user  
typing into a text field, pasting a new value into the field, or undoing  
an edit in that field. Some user interactions do not cause changes to the  
value, e.g. hitting the "delete" key in an empty text field, or replacing  
some text in the field with text from the clipboard that happens to be  
exactly the same text."

That helps a lot, including indirectly showing what "change" means.


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


I see. It says the input and change events do not apply to the reset  
control.


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


Maybe nothing?


Your text below is much clearer than WF2's, so I just might not have  
understood what WF2 was saying.


"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)?


I'm concerned because current input event support across Firefox, Safari  
and Opera isn't exactly the same. Wouldn't want anything to be up in the  
air as how it's done in an HTML5 UA.


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


In that case, I see.


Thanks very much.


A couple other things:


1. I do not see the oninput attribute defined anywhere.


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>)?


Thanks

-- 
Michael

Received on Wednesday, 12 November 2008 05:26:51 UTC