W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Detecting support for a given HTML5 feature through JS (was: Re: HTML Extensibility Through Script)

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 15 Jul 2007 21:45:09 +0300
Message-Id: <3BE68223-C9A7-4B2A-A076-CA6BF4857021@iki.fi>
Cc: "Doug Schepers" <doug@schepers.cc>, "public-html@w3.org" <public-html@w3.org>
To: Jon Barnett <jonbarnett@gmail.com>

On Jul 15, 2007, at 20:40, Jon Barnett wrote:

> Hixie pointed out that you can detect support for certain features
> using Javascript [1], such as writing PING as uppercase in the DOM,
> and then checking the HTMLAnchorElement.ping property (lowercase).  I
> suspect the same logic can apply to new input/@type values - use
> <input type="date">, and then check the HTMLInputElement.type property
> for either "date" or "text".

This is the best way because the test for the existence of the  
implementation involves testing the implementation itself.

> But a unified method would be nice.  Such as a
> DOMImplementation.rendersElementNS(strNS, strElementName) function,
> and a complementary .rendersAttribute function?
>
> Either that, or an enormous number of hasFeature strings...

These are problematic, because the claim of support is detached from  
the actual support. It isn't feasible to subdivide features down so  
that each minute subfeature had its own string. Browsers will likely  
claim that they support a feature even when the support is not full.  
OTOH, an implementation may indeed support something but have a bug  
in the hasFeature impl.

Given that hasFeature can be wrong accidentally or deliberately, I  
think we shouldn't add more feature strings and we should encourage  
script authors to poke the actual features to see if they are there.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Sunday, 15 July 2007 18:45:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT