My sincere thanks for taking up this issue! Having to build applications for both mobile as well as stationary clients, I claim that the onchange behavior, as implemented (differently) across the browser spectrum, is most frustrating. Generally, I've just "punted" and implemented something based on onblur instead. Improvements to the clarity of the specification are eminently desirable.
Imagine having to change reservations while being in (hopefully, not driving) a vehicle bouncing along a bumpy road. If you fail, you get to spend the night in some bedbug infested "hotel." Your mobile browser handles onchange in an annoying manner, and the WWWeb site was not designed to compensate. Do this but once, and you will abandon all other efforts in order to fix the problem. Best! BdG ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tab Atkins Jr. Sent: Thursday, 2008 October 30 08:19 To: Garrett Smith Cc: [EMAIL PROTECTED]; Ian Hickson Subject: Re: [whatwg] Web Forms: change event On Wed, Oct 29, 2008 at 11:32 PM, Garrett Smith <[EMAIL PROTECTED]> 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
