Grauw’s blog

So, Firefox 3.6 is released, and FCKEditor breaks. Blame is assigned to browser detection, feature detection is promoted as the be-all end-all solution.

Except that browsers tend to implement their new features in a broken way. D’oh.

The node.children.tags() method is a good example. Originally an IE-ism/feature, which can be useful for a slight performance optimisation. Along comes Safari with support for tags() but returning nodes from the entire document instead of just the child nodes.

Firefox then decides to implement the children collection as well, however without tags() method and thus incompletely, again breaking my feature detection. And finally Opera goes in for the kill by throwing an exception when tags() is used in a document parsed as XHTML (iirc).

So after having to fix this stupid optimisation in my Selectors implementation three times, what did I end up doing? Right,

if (browser_ie)
   return node.children.tags(name);

Another example of feature detection gone awry we had at Backbase when IE8 introduced JSON support. IE8 manages to serialise XML DOMStrings (e.g. retrieved from getAttribute()) to null instead of "". Had we used browser detection instead of feature detection, the issue would not have occurred.

Feature detection is overrated. Because of this kind of crap I went back to (a sensible form of) browser detection, with the much more workable presumption that once implemented, browsers will not remove or break existing functionality. Yes, when the browser gets native support for whatever you want to use, it runs a little slower than possible initially. But in exchange you get the opportunity to explicitly test the feature before using it it.

Now I’m not saying feature detection is never good, there are cases where what you want to use is relatively simple, standardised and often-used on the web, like the addEventListener() method, and for such things feature detection is probably a safe bet. But be careful, and do realise that the history of browsers has shown that they very very much like to implement their new APIs and technologies in a broken way the first time around.

And there is of course the one golden rule: never depend on broken behaviour.

Grauw

0 comments [reply]

Comments

None.

» Add a comment…