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

This is my preemptive detailed review of the DOMControlValueChanged
and 'input' events. (I've mentioned bits and pieces of the below
before in various threads/comments.)

<http://www.whatwg.org/specs/web-forms/current-work/>:

WebForms 2 specifies both the DOMControlValueChanged and input events.
These events attempt to solve the problem of detecting all types of
changes to a control's value with just one event. However, before they
are added to HTML 5 (and they both should be as part of forms stuff),
lots of things need to be cleared up as the events are currently way
underspecified.

In short, DOMControlValueChanged is supposed to fire whenever the
control's value is changed. The input event is a
user-initiated-filtered version of DOMControlValueChanged.
DOMControlValueChanged can only be attached with addEventListener (or
IE's attachEvent I guess). 'input' can be attached with
addEventListener, control_element.oninput = function and oninput="js".

<http://www.whatwg.org/specs/web-forms/current-work/#the-change>
http://www.whatwg.org/specs/web-forms/current-work/#the-domcontrolvaluechanged

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

For example, if I press del in an empty type="text" field, the value
doesn't technically change, but should the input event fire or not? In
Opera and Safari, it does. In Firefox it doesn't and IE's
onpropertychange seems to agree with Firefox. If I do textarea.value =
textarea.value should DOMControlValueChanged fire?

Now, it does say that it's "otherwise identical to the change event".
However, there are differences there too. Opera and Safari fire
onchange when you press del in an empty text field and remove focus.
Firefox and IE do not. This makes "change" confusing. Personally, if
the value didn't change, I don't think the events should fire and I
think Firefox is correct.

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.

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.

Also, if I attach DOMControlValueChanged to a control, change its
value and inside the called function, the JS changes the control's
value, does DOMControlValueChanged get called again, or should that be
prevented?

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

Current browser support/bugs (in addition to any browser
quirks/differences mentioned above):

Firefox doesn't seem to support control_element.oninput. You have to
use addEventListener or @oninput. Firefox doesn't seem to support
oninput on very many controls, just textareas and type="text" fields.
Firefox seems to fire exactly once for each change and supports firing
for changes caused by pasting. However, it doesn't work for drag and
dropping text (from the address field for example).

Safari doesn't seem to support oninput on textareas at the moment due
to a regression. It does work on type="text" fields right now, but not
on any other elements that I've noticed. Safari supports (in text
fields currently) firing for pasting, drag and dropping and undo/redo
etc.

Opera supports oninput on lots of controls (including SELECT and
type="checkbox"). However, it fires the event twice for each change.
It supports firing for pasting, drag and drop and most other user
methods of changing the control's value. However, with some of the
actions, the input event won't fire until you remove focus off the
control and cause the change event to fire.

Currently, neither Firefox or Safari support DOMControlValueChanged.
Only Opera does.

-- 
Michael

Received on Tuesday, 30 September 2008 02:39:44 UTC