- From: Robin Berjon <robin@berjon.com>
- Date: Thu, 20 Jan 2011 12:02:43 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: public-html-xml@w3.org
On Jan 20, 2011, at 10:55 , Henri Sivonen wrote:
> 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.
Note that this scenario isn't fictitious, it's actually happened.
The reverse is also true. It's happened that browsers have shipped with a feature correctly supported while the corresponding hasFeature() returned false.
Web development is defensive by nature. You essentially have to treat browsers as a bunch of somewhat sleazy politicians: you don't act based on what they tell you, you act based on what you see them actually doing. Standards certainly help, but solutions like hasFeature() are the equivalent of getting them on a new talk show rather than creating more transparency.
--
Robin Berjon - http://berjon.com/
Received on Thursday, 20 January 2011 11:03:29 UTC