W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2008

[whatwg] Web Forms: change event

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 30 Oct 2008 07:19:19 -0500
Message-ID: <dd0fbad0810300519q2ed422a5q24ee0fc1dc6d0c9f@mail.gmail.com>
On Wed, Oct 29, 2008 at 11:32 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> Ian Hickson wrote:
>
>> On Wed, 6 Jun 2007, Sander wrote:
>>
>>> The specs say that for <select> "...the change event shall be fired when
>>> the selection is completed...". Does this mean that, when using a keyboard
>>> for navigation, the change event is fired when the user hits 'enter' or when
>>> she navigates from one option to another? I assume it's the former, but I
>>> just to be sure as selectboxes with change event handlers are often (ab)used
>>> for navigation purposes. So, can anyone confirm my assumption? Thanks.
>>>
>>
>>  The HTML 4 specification[1] says:
>
> | The onchange event occurs when a control loses the input focus and its
> | value has been modified since gaining focus.
>
> A "test case"[2] I found does expects that onchange fires when the select
> has been changed and while it still has focus.
>
> | Procedure
> |   1. Using the keyboard or an assistive technology that emulates the
> | keyboard, move focus to the select control.
> |   2. Using the keyboard or an assistive technology that emulates the
> | keyboard, select a value from the menu to trigger the onChange event.
>
> [example]
>
> | Expected results
> |
> |   1. A star colored according to the select option value appears when
> | the onchange event is triggered.
>
> Firing onchange before the select loses focus does not follow the HTML
> specification but is more useful and is what browsers mostly do.
>
> Often, a select is used to trigger another action, such as showing more
> fields in a form. The user chooses an option and, based on the selection, a
> section of the form is shown. If the change event does not fire when the
> item is chosen, the callback will not be called and the user will not see
> the event until he changes focus by tabbing or clicking away.
>
> Instead, the chagne event should (ideally) fire when a different option has
> been selected.


Goodness no.  <select>s firing their onChange when different options are
selected are horrifying for keyboard navigation.  You ever been to a site
that uses a select and an onChange handler to do some quick navigation?  It
becomes impossible to use the keyboard as intended, because the very first
option that comes up when you use your arrow keys or type part of the name
triggers the navigation.

Waiting until they lose focus is very slightly clumsy in some uses for users
with a mouse, but it's a necessity for alternate input devices like a
keyboard.

~TJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081030/526ea8cf/attachment.htm>
Received on Thursday, 30 October 2008 05:19:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:06 UTC