W3C home > Mailing lists > Public > public-html@w3.org > December 2008

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

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Tue, 02 Dec 2008 06:59:52 -0500
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-html@w3.org
Message-ID: <op.uli992c71ejg13@sandra-svwliu01>

On Tue, 02 Dec 2008 05:40:26 -0500, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 12 Nov 2008, Michael A. Puls II wrote:
>> > >
>> > > 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.
>
> Yeah the meaning of "change" is an open issue I'll have to address. I've
> noted it in the spec.

O.K.

>> 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)
>
> Right, this will be defined when "changed" is defined.

Cool.

>> "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)?
>
> It seems like defining this level of detail is unhelpful since it will be
> affected by things like CPU speed, which isn't under our control.

O.K.

>> 1. I do not see the oninput attribute defined anywhere.
>
> Yeah I am planning on going through and adding all the event handler
> attributes at a later date when the events are more stable.

O.K. cool.

>> 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>)?
>
> For <input>, see:
> http://www.whatwg.org/specs/web-apps/current-work/#event-input-input
>
> I just added the same text to <textarea>, which I'd forgotten.
>
> It indeed doesn't apply to <select> right now. 

Opera is the only one that supports it on <select>. Opera supports it on checkboxes  and radio buttons too. This is probably because WF2 basically talked about 'input' as a change on any form control.

> Should it?

Not sure. I know nothing that depends on it for <select> except for some test caases.

-- 
Michael
Received on Tuesday, 2 December 2008 12:00:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:27 GMT