Re: Detecting support for a given HTML5 feature through JS

On Jul 16, 2007, at 01:21, Doug Schepers wrote:

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

Sure. On the Web, there's always a counter example that makes a best  
practice not 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?

Testing for MathML *rendering* is relatively unusual. Usually,  
scripts test DOM API presence because they are about to use an API.

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

Yes, it may be unintuitive and complex. However, a test that actually  
pokes a feature to see if it is there is by its nature more reliable  
than a test that asks another piece of code to make a statement about  
a feature.

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

It was based on reasoning like this:
A feature string covers subfeatures 1 and 2. Browser A implements  
those and returns true for hasFeature. Authors start using subfeature  
1 often but not subfeature 2. Browser B is now tempted to return true  
for the feature string as soon as subfeature 1 is implemented even if  
subfeature 2 isn't.

> In fact, Firefox claims *no* support for MathML,

No support for the MathML DOM interfaces.

> though it can render it.  Can you devise a test for that?

It would be easier to test for the presence of a MathML UA style  
sheet: a script could test if the computed style of an element that  
is supposed to be italicized by default indeed indicates italics.

I guess one could test the general presence of a MathML renderer in  
general by including a two-row matrix and a one-row matrix inside  
divs and then query the offsetHeight of the wrapping divs.

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

In the case of the Web application features of HTML 5, the DOM  
interfaces are such an important part of the feature that a given  
element provides that a sane implementation worth detecting is likely  
to support them. This isn't applicable to the new document  
structuring feature which are more similar to the MathML issue.

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

Yes, that's a problem. But it is code that is more likely to give a  
useful answer.

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

It is an approach that works, though. It seems implausible that there  
could be an elegant general solution that was also as reliable as  
Hixie's test.

A new API could only ever be as reliable as poking the actual feature  
for completely new features. If we came up with an API to query a  
layout engine for MathML rendering support, shipped Gecko would not  
have that API but does have rendering support. Hence, the new API  
would always be less reliable than something that pokes the actual  
implementation.

> Each test would itself be a challenge to moderately competent  
> authors, and a great difficulty to the majority of authors.

Agreed. However, it seems to me that the challenge to write code that  
runs on in number of different environments with different features  
available has some inherent difficulty.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 16 July 2007 08:07:57 UTC