RE: Replacing the event keyCode value.

What I was quoting was the CR for DOM events that I used when doing one of the first implementations.

The editor’s draft for 4 does describe the event listeners as a static list at the time of invocation, but the list is built by appending items only if there is not already a matching item in the list. The DOM 3 spec also describes the handling of duplicate registration which may affect the order in which listeners are added.

The DOM 3 spec also warns about event listeners being registered by means other than script. This could affect order of execution:

Note: In addition to the EventTarget.addEventListener<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-EventTarget-addEventListener> method, some host languages<http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#glossary-host-language> may allow a content author to register event listeners by the use of attributes, e.g., onclick="handleClick()". Because the details of this are often language-specific, this type of event listener registration is not defined in this specification, but in general, any event type may be used as an attribute in this way by adding the prefix on- to the event type name, and events so dispatched should behave consistently with the event registration and propagation defined in this specification, with the same interfaces, properties, and methods.

I’m not sure why you claim it would cause interop problems. Any interop problem that is caused by something as fragile as expecting event listeners on a single node to execute in a particular order is an indication of poor design of the page itself, not the user agent or implementation. Even the order in which web responses for script and images and their subsequent load events which might add/remove eventListeners may vary between implementations.

The point of the keydown/keyup being a physical key transition not necessarily related to a keypress or textinput is still valid. Textinput is probably a safer mechanism for achieving the desired behavior.


From: Glenn Maynard [mailto:glenn@zewt.org]
Sent: Thursday, December 01, 2011 7:20 PM
To: Brad Pettit
Cc: João Eiras; www-dom@w3.org
Subject: Re: Replacing the event keyCode value.

On Thu, Dec 1, 2011 at 8:53 PM, Brad Pettit <Brad.Pettit@microsoft.com<mailto:Brad.Pettit@microsoft.com>> wrote:
Having the keycode modifiable would be problematic because multiple listeners may be attached to an EventTarget, and the order of execution for EventListeners on any given node is not defined. In one implementation, the listener that modifies the code might execute first, while on another, it might execute last.

<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-basic>
"Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget"

You're reading a spec from over a decade ago.  This would never be acceptable today; it would cause major interop problems.  DOM4 defines event listeners as a list, and that's what all modern browsers implement.  http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#events


(I suspect DOM3 says the same thing, but I'm not as familiar with that spec.)
--
Glenn Maynard