Re: HTML Extensibility Through Script

On 7/15/07, Doug Schepers <doug@schepers.cc> wrote:
>
> It's been pointed out to me off-list that the reason that Firefox
> doesn't return true to hasFeature("org.w3c.dom.mathml", null) is that
> while it does in fact render MathML visually, it doesn't support the
> MathML DOM interfaces [2][3].

Well, that feature string is for the MathML DOM.  Maybe there should
be a different feature string for /rendering/ MathML than there is for
supporting its DOM interfaces.

> So, it's difficult to say if FF supports MathML or not.  If it simply
> supported the shapes and rendering of SVG without the DOM interfaces,
> I'd say it's not a very good SVG implementation, but some useful things
> could still be done with it.

Right, and the same concept applies to HTML 5.  There will be UAs that
render (if that's the right word) certain parts of HTML 5, but don't
support their DOM (I don't have an offhand example), and of course UAs
that support some features of HTML 5 but not all (current browsers
that support <canvas> or @ping, but not all new <input> types)

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

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

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-October/004898.html

Jon Barnett

Received on Sunday, 15 July 2007 17:40:10 UTC