Firechicken
Saturday, 23. December 2006, 19:39:36
Over at Mozilla.org they've been working on fixing their load events capture bug. That's great news, because Opera has had lots of trouble with sites that used event capture when they didn't intend to do so. We had the correct, spec-compliant implementation. However, web developers don't read specs. They test in browsers. We suffered the incompatibility problems because sites were written for Firefox's implementation. We've had ugly problems caused by this issue for years, on extremely important sites like AOL.com, and we've worked hard through Open The Web, information and even site patching.
Inevitably, when Firefox fixes the bug they run into those badly coded sites. They start seeing the problems we've had all along. So what do they do? They play chicken! They decide to tweak the spec to solve the problem their bugs created in the first place.
If they go for this solution, we have to follow them for compliance.
To be fair, I do think that aligning a spec to the web can be a good solution, as long as it ensures interoperability and covers the use cases. And the DOM2 Events spec itself is vague. I guess the problem is a spec that attempts to be so language-generic that it avoids referring to even the all-important JavaScript window object, it isn't clearly specified where the window object fits into the event capture/bubble model. They can and probably will argue that their implementation is DOM conformant (and make sure the HTML5/web apps spec lands on their side?).
I'm still disappointed.
Inevitably, when Firefox fixes the bug they run into those badly coded sites. They start seeing the problems we've had all along. So what do they do? They play chicken! They decide to tweak the spec to solve the problem their bugs created in the first place.
If they go for this solution, we have to follow them for compliance.
To be fair, I do think that aligning a spec to the web can be a good solution, as long as it ensures interoperability and covers the use cases. And the DOM2 Events spec itself is vague. I guess the problem is a spec that attempts to be so language-generic that it avoids referring to even the all-important JavaScript window object, it isn't clearly specified where the window object fits into the event capture/bubble model. They can and probably will argue that their implementation is DOM conformant (and make sure the HTML5/web apps spec lands on their side?).
I'm still disappointed.
WIDGETIZE
Andrew Gregory # 24. December 2006, 01:18
FataL # 24. December 2006, 01:52
Shure that Google donesn't want to fix all their applications...
_Grey_ # 24. December 2006, 02:12
(guess whom that should resemble...)
hallvors # 24. December 2006, 13:56
xErath # 26. December 2006, 14:47
Tipical monopolistic BS.
Could you make some noise at the www-dom list, saying "bla bla bla, the spec has to become mozilla compliant because they don't want to fix their bugs bla bla bla"
FataL # 26. December 2006, 15:53
HeroreV # 31. December 2006, 09:59
* What should currentTarget refer to?
window.addEventListener('click', function(event) {
alert(event.currentTarget);
}, false);
The DOM 2 Events spec says it should refer to "the EventTarget whose EventListeners are currently being processed". If the listener was attached to window, shouldn't currentTarget refer to window?
* When should the listener be called for the HTMLDocument load event?
window.addEventListener('load', listener, true);
window.addEventListener('load', listener, false);
If the listener is actually attached to window, and the document is a child of window, the listener should be called during the capture phase. Since the listener isn't attached to the document, and since load events don't bubble, the listener shouldn't be called during the bubbling phase.
hallvors # 31. December 2006, 11:49
If compatibility with existing content is the name of the game (which it is unless Moz+Saf+Opera decide to go for consistency and continue the massive evangelism campaign Opera has been doing alone so far) we must ignore the "capture" argument for load events and specify a "limited bubble hack" that makes the document's load event bubble to the Window.
On Digg you commented "I'd really prefer that event listeners weren't ever allowed to be attached to the window object to begin with" - indeed. I seem to remember that we support this merely because it's What Gecko Does (tm). Load event listeners added to document never fire(d?) - before we ran into this problem Opera actually didn't implement window.addEventListener at all since, as we know, the window object isn't part of the DOM nor the DOM events spec...
HeroreV # 31. December 2006, 19:38
I dunno how much Opera has done in comparison to everyone else, but Opera certainly isn't the only one trying to evangelize the web.
> If compatibility with existing content is the name of the game ... we must ignore the "capture" argument for load events and specify a "limited bubble hack"
Actually, Gecko calls listeners during the capture _and_ bubbling phase for the document load event! Opera already does it wrong for compatibility, so why no go ahead and make it completely compatible? It's already bubbling the document load event up to window.
The global addEventListener function is a mess, and I would prefer that it just be marked deprecated rather than trying to fix it.
hallvors # 3. January 2007, 11:34
I never said or meant that. However, we've been struggling with this problem for a *long* time so naturally it annoys me to see Gecko get away with rewriting the spec like that, even when I can appreciate it from a pragmatic point of view. Hey, on both the event capture bugs [1] we have a "biggest implementor gets to rewrite spec" effect. I hope it doesn't become a Gecko habit..
> The global addEventListener function is a mess
..but we have no choice but trying to fix it, since it is so widely used. Thanks again Gecko.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=235441 is the other one
xErath # 4. January 2007, 06:28
Chas4 # 24. April 2009, 22:39
tudsta # 20. May 2009, 15:12