Safari lies
You know, the Document Object Model gives us a wonderful method called hasFeature(), which gives browsers a chance to indicate what parts of the specification that they properly support. The idea being that developers could query this method to determine what parts of the DOM are available. This works great in theory, but it falls completely apart when browsers lie. And Safari lies.
I’m using Safari 2.0.3 on my Mac Mini. I was trying to use mouse events as defined in DOM Level 2. If I run document.implementation.hasFeature("MouseEvents", "2.0"), it returns true. However, if I create an event and try to call initMouseEvent(), the initializer for DOM mouse event objects, I get an error. Why? Because the method doesn’t exist. Further, the initUIEvent() method doesn’t exist either…but mouse event is a subclass of UI event, so it that method should be there too. That means not only does document.implementation.hasFeature("MouseEvents", "2.0") return an incorrect value (true), but document.implementation.hasFeature("UIEvents", "2.0") is also incorrect (returns true as well).
What is the point of having these standards if browser vendors aren’t honest. At least in IE, pretty much everything returns false…thanks for being honest! When browsers lie about their capabilities, developers end up spending an unnecessary amount of time tracking down what exactly is breaking. Especially for Apple, which aims to be conformant to the specifications, this is a huge step backwards.
To be fair, I checked the last nightly of WebKit, and this issue appears to be fixed. But still, because Safari lied initially, I need to do extra tests to figure out if I’m using a truthful version or not. Ugh.
P.S. Thanks to everyone who sent emails and left blog comments of support for my last post. It really meant a lot to me. I may not be back to full form right now, but I’m getting there slowly. Thanks.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
5 Comments
I still hate Safari. I thought I’d share that
.
Jeremy on May 8th, 2007 at 1:09 pm
Sorry that the bug caused you problems.
Generally, testing for the method you care about directly (for example, "initMouseEvent" in someMouseEvent) is likely to be more accurate than hasFeature. It can’t be wrong about whether the method is there if the browser developers made a mistake, unlike hasFeature, which has no direct relationship to the code for the feature. hasFeature can also be wrong in the other direction.
Hope this helps.
Maciej Stachowiak on May 9th, 2007 at 5:05 am
Welcome back Nicholas! I hope this time helped you…
PS: I’m in the same situation you were now… =..(
Guilherme Blanco on May 10th, 2007 at 10:59 pm
Hi Maciej – Thanks for responding. I understand your point, testing for the method specifically is, of course, more accurate in general. However, I believe that hasFeature() was designed to encompass a number of methods and properties so that individual tests needn’t be done. In order to test for initMouseEvent(), I must first create an event. Since createEvent() is supported, I can use that, but the event object returned when I pass in "MouseEvents" is a crippled MouseEvent object that doesn’t behave correctly (I can’t set any mouse-related properties). So then I need to create another event object and pass in "UIEvents" to get an event object I can actually use. If a feature like hasFeature() isn’t implemented correctly across browsers, what’s the use of it?
Nicholas C. Zakas on May 11th, 2007 at 3:10 am
It sounds like Maciej Stachowiak wants to justify the lies of Safari for the cases of MouseEvents.
But Safari lies also – for example – in this case
if(document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#SVG","1.1"
)
This a relatively new and fast feature e.g. needed for drawing polylines in Google Maps. And there is no other known method to ask for the browsers SVG support.
So whats the result? The users of Safari won’t see polylines.
At least I would mean that the lies of Safari are despicable and unjustifiable.
Wolf Pil on August 1st, 2007 at 9:22 am
Comments are automatically closed after 14 days.