Re: addEvent - The late entry :)

On Jul 20, 1:37=A0am, Thomas 'PointedEars' Lahn <PointedE...@[EMAIL PROTECTED]
>
wrote:
> dhtml wrote:
> > On Jul 19, 6:49 pm, "Aaron Gray" <ang.use...@[EMAIL PROTECTED]
> wrote:
> >> Here's yet another mod :-
>
> > There are some significant differences in attachEvent and
> > addEventListener.
>
> > * w3c DOM Event bugs in Webkit and Safari (and probably a lot in Opera
> > that I'm not aware of).
>
> Could you elaborate on that, please?
>

In Webkit and Firefox (I meant to say), events fire on bubble when
useCapture has been set to true. This is a bug and in direct violation
of the Events spec, which states:

| useCapture of type boolean
|    If true, useCapture indicates that the user wishes to
| initiate capture. After initiating capture, all events of the
| specified type will be dispatched to the registered
| EventListener before being dispatched to any EventTargets
| beneath them in the tree. Events which are bubbling upward
| through the tree will not trigger an EventListener designated
| to use capture.

"Events which are bubbling upward through the tree will not trigger an
EventListener designated to use capture."

https://bugzilla.mozilla.org/show_bug.cgi?id=3D235441
https://bugs.webkit.org/show_bug.cgi?id=3D9127

The spec statment was strengthened in D3E:
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-EventTarget-addE=
ventListener

| useCapture of type boolean
|   If true, useCapture indicates that the user wishes to add
| the event listener for the capture phase only, i.e. this
| event listener will not be triggered during the target and
| bubbling phases. If false, the event listener will only be
| triggered during the target and bubbling phases.


> > * w3c DOM Events bubble as specified, IE events bubble differently,
> > like legacy events (by "legacy" events, I mean el.onclick =3D ...)
>
> Could you provide a test case that demonstrates the issue, please?
>

I was wrong about the legacy events bubbling differently, but not
about IE DOM Events. They don't bubble the same.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-h=
tmlevents

| change
| The change event occurs when a control loses the input focus and its
| value has been modified since gaining focus. This event is valid for
| INPUT, SELECT, and TEXTAREA. element.
| Bubbles: Yes
| Cancelable: No
| Context Info: None
|
| submit
| The submit event occurs when a form is submitted. This event only
| applies to the FORM element.
| Bubbles: Yes
| Cancelable: Yes
| Context Info: None

Both of these events should bubble.
Moz and Safari: these events bubble when registered with
addEventListener.

IE: these events don't bubble

MSDN docs
 onchange: http://msdn.microsoft.com/en-us/library/ms536912(VS.85).aspx
 onsubmit: http://msdn.microsoft.com/en-us/library/ms536972.aspx

I'll post up an example tomorrow.


> > * different thisArg - attachEvent's this is always window
>
> and
>
> * event listeners *added* with addEventListener() are executed
> =A0 *in order of addition*;
>
> =A0 event listeners *attached* with attachEvent() are executed
> =A0 *in arbitrary order*
>

Good to know, but I can't think of a good reason for relying on the
order.


> PointedEars