Re: Detecting support for a given HTML5 feature through JS

Hi, Henri-

Henri Sivonen wrote:
> 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.

In certain cases, this is a reasonable statement.  But it isn't 
universally applicable.  For instance, if you'll look at another MathML 
testcase [1], you'll see the problem.

Firefox can render MathML; Opera cannot.  Neither can render FooML 
correctly (where FooML is exactly the same as MathML, but in a different 
namespace, and which should render identically).  Yet I can see no way 
to test the rendering of the FooML via script (though it's obvious upon 
visual inspection); FF does not provide a special DOM for either, so how 
would you test for the existence of uniquely MathML (or FooML) 
properties?  The namespace is there, the structured markup is there, but 
the rendering is not testable.


>> 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. 

And yet, as I've shown, you simply can't test certain things... and even 
those thing you can test may require a complex and unintuitive test.


> It isn't feasible to subdivide features down so that
> each minute subfeature had its own string. 

It certainly is possible, but it may not be pragmatic, and it may not be 
desirable.  Feature strings to test each given combination of elements, 
attributes, and parent-child node relationships is obviously not 
reasonable.  I think that the real answer lies somewhere in the happy 
medium of a well-designed language that provides key feature strings... 
for example, on the module or chapter level.


> Browsers will likely claim
> that they support a feature even when the support is not full. 

Can you provide evidence for that claim?  In fact, Firefox claims *no* 
support for MathML, though it can render it.  Can you devise a test for 
that?


> OTOH, an
> implementation may indeed support something but have a bug in the 
> hasFeature impl.

An implementation may equally have a bug that prevents the feature from 
being tested correctly via the element-creation test.  Neither method is 
infallible.


> 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.

This isn't a very scalable solution, either, because authors would have 
to spend significant amounts of code checking for particular features 
before using them.

Hixie's test is clever... too clever.  It's an idiosyncratic, ad hoc 
solution that is unsuitable for dealing with a wide variety of languages 
and modalities.  Each test would itself be a challenge to moderately 
competent authors, and a great difficulty to the majority of authors.

And though you've changed the topic in the subject line, this entire 
line of inquiry is to determine a reasonable way to extend browsers to 
cover other languages than HTML.  Since this is a very common case, it 
should be built into HTML.


[1] http://schepers.cc/standards/MathML/mathMLTest2.xhtml

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Sunday, 15 July 2007 22:21:15 UTC