W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2011

Re: Event for form element changes (onvaluechanged)

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 8 Apr 2011 13:07:15 +1000
Message-ID: <BANLkTinMyxeb3DYSP75oCSTmQcUSc+9=KQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: "www-dom@w3.org" <www-dom@w3.org>
I believe the "input" event (in the HTML5 spec) is what you're looking for
and is already widely implemented.

On Fri, Apr 8, 2011 at 11:46 AM, Glenn Maynard <glenn@zewt.org> wrote:

> The onchange event is only fired when an element loses focus.  This
> optimization may have made sense when Javascript engines were so slow that
> running scripts on each input was a bad idea, but it's a hassle now.  Many
> interfaces today update as the user types.
> This requires jumping some hoops, since there's no way to catch everything
> that might change an input box.  Even if you watch onkeypress, oncut and
> onpaste, you'll miss things like Chrome's clear-input button.  (WebKit also
> doesn't fire onkeypress consistently.)  The only reliable option is to set a
> repeating timer to check the value continuously, which is wasteful.
> A "valuechanged" event should be fired after the value changes for any
> reason.  To handle multiple items changing at once (radio boxes,
> form.reset()), it should be async.  (This name makes the most sense for text
> inputs, but the event should apply to the same elements that onchange does.
> (This differs from textinput.  textinput is only fired when text is
> entered, not when it's removed; textinput is fired before the value changes,
> not after; and textinput doesn't apply to all form inputs, just text.)
> --
> Glenn Maynard
Received on Friday, 8 April 2011 03:08:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:17 UTC