DOM Event Scripting, (undocumented) Tip #2: Safari and the Microsoft Event Model

[jkd]

Despite Apple's website saying that you can only use the one W3C DOM Event model in Safari, the KHTML developers tossed in complete emulation of everything IE does (including the existence of the window.event object), and was incorporated into Safari (and of course, Konqueror).

One caveat is that event.srcElement == event.target, so you can't use srcElement to get around the text node targetting issue that Safari has.

This isn't so much a tip as it is a curious tidbit, though it may help cross-browser script debugging.

[MikeFoster]

Very interesting.

For a browser vendor, choosing to emulate IE's event or object model means having to decide whether to continue IE's quirks in their emulation. I have to wonder if it doesn't just complicate the issue for developers when they don't emulate the quirks. :)

[brothercake]

It's a curious question though - where did this come from and why? Konqueror does claim support for document.all as well - I always assumed it was just a spoofing property, but now I'm wondering whether the .all collection is in fact implemented for real ...

[MikeFoster]

This topic brings up another interesting point. Non-IE browser makers would like to move users away from IE and its object/event models, yet they obviously feel the need to emulate IE's object/event models so their users won't complain about so many pages on the web which then would not work in their browser. By implementing IE-emulation it seems to me they are slowing progress of their own goals. Quite a catch-22 ;)

You might think that Gecko browsers did not do this - but they did. They implemented IE's offsetXXX properties (with the same semantics as IE). To me this was an admission that the DOM methods were insufficient - the offsetXXX properties were really needed - at least until the appearance of a trustworthy getComputedStyle method ;)

[jkd]

the offsetXXX properties were really needed - at least until the appearance of a trustworthy getComputedStyle method ;)

I think it was more of a matter that every other browser had offset properties, and no other browser had a getComputedStyle() (and even Gecko's implementation was slightly buggy - not a deficiency in the standard itself, just the implementations), and most every developer knew about the offset properties, whereas very few had gone through and read through the DOM2 Style specification. I'm still waiting for the OverrideStyle myself, but whatever.

In any case, we're approaching a web of highly interactive interfaces. Gmail, Google Maps, etc are all doing things that could have been done years ago, but they are the first major company to put that much of a trust in DHTML web apps. Including low-cost properties like the offset ones I would like to think brings us closer to this future faster than if we waited forever for everyone else to support computedStyle.

However, with Konqueror and document.all, or KHTML and Microsoft's window.event, I don't think their adoption brings us any closer to that goal, when developers are writing code to accomodate the proper way of doing those things anyway.

[MikeFoster]

You make some excellent points - and I think we're 'almost' completely in agreement ;)

But I've taken this thread offtopic - so I'll stop :)

Thanks!