W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: The interpretation of script

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 20 Jan 2011 01:55:45 -0800 (PST)
To: public-html-xml@w3.org
Message-ID: <1392006413.44472.1295517345049.JavaMail.root@cm-mail03.mozilla.org>
Kurt Cagle wrote:
> Perhaps this points to a potential feature for HTML that could prove
> very
> useful. In XSLT there's an XPath command called
> xsl:function-available()
> which will return true if the named function is available on the
> system.
> Perhaps something similar on the JavaScript side, e.g.,
> feature-available(),
> could be used to determine whether a given capability such as MathML
> is
> actually supported on the system in question?

For individual functions, you can already use JavaScript to sniff it they exist:
if (document.getElementByClassName) {
  // code that calls document.getElementByClassName

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.

Henri Sivonen
Received on Thursday, 20 January 2011 09:56:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:27 UTC