Re: Replacing the event keyCode value.

On Thu, Dec 1, 2011 at 10:57 PM, Brad Pettit <Brad.Pettit@microsoft.com>
wrote:
> What I was quoting was the CR for DOM events that I used when doing one
of the first implementations.

And it's incorrect today.  It worried me to see an employee of a major
browser vendor quoting long out-of-date and now incorrect text from ancient
specs, so I wanted to make sure this was clarified and that people aren't
still looking at DOM2.

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

Sure.  It doesn't matter that it affects the order; what matters is that
the effect is the same across browsers.

> 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 method, some host
languages 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.

Which, again, is clearly specified in their relevant specs, so the results
are consistent and well-defined.

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

Whether something is "poor design" or not (and I disagree that depending on
the event order is in any way "poor design") is irrelevant to whether its
consequences are interop problems or not.  If an API behaves differently in
different browsers, and this results in pages that work in one browser and
not in another, it's an interop problem, no matter how much you don't like
the code that's triggering it.

--
Glenn Maynard