Re: The interpretation of script

> Having something like DOM's hasFeature detect for larger sets of features doesn't work on the Web. Here's a scenario that explains why:
>   1) The browser with the most market share implement a set of features called Foo. The implementation is full of bugs, but they make hasFeature("Foo") return true.
>   2) $IMPORTANT_SITE notices that there's a corner of the Foo set of features that's not too buggy to use.
>   3) They use that corner, but put the code behind a hasFeature("Foo") check.
>   4) Browsers with less market share see that their users aren't getting the full experience of $IMPORTANT_SITE.
>   5) At least one of the browsers with less market share quickly implement the corner of the Foo set of features that $IMPORTANT_SITE uses and makes hasFeature("Foo") return true in order to make the code run even though the rest of the Foo feature set remains unsupported.
>   6) hasFeature("Foo") has been poisoned and can't be relied on.
>
Sadly, this tale seems to be true - people will write content that only 
works if the browser says it is Jingo version 2.5, and browser vendors 
will respond by claiming that their browser is Jingo version 2.5.

Personally, my response to this is the brutal one: conform to the rules 
in your own product, and make no concessions to people who don't. It's 
tough, but people will respect you for it, and in the end, the people 
who don't conform will be left out on a limb and will change.

But I guess that's diametrically opposed to the html/web culture, so I'm 
on a losing wicket.

Michael Kay

Received on Thursday, 20 January 2011 11:50:46 UTC