Re: HTML Extensibility Through Script


See follow-up comment inline.

Doug Schepers wrote:
> Hi, Jon-
> Jon Barnett wrote:
>> On 7/10/07, Doug Schepers <> wrote:
>>> This seems to have drifted off-topic rather quickly... To refocus, I
>>> wasn't asking for a way to sniff browser strings, which is a brittle way
>>> to determine the featureset of the UA.  I intended this thread to
>>> discuss the possibility of conditional operators, either through a
>>> script API or (preferably) via a declarative markup or featurestring.
>> Is there a use case that isn't covered by DOMImplementation.hasFeature()?
> Possibly not.  Honestly, I hadn't considered "hasFeature()" for this, 
> though I agree it does fit the bill for the scripted API, assuming that 
> it is properly supported (see below).
> I still think that a declarative 'switch' feature or the like is a 
> better choice, more generic, more powerful than a simple fallback 
> mechanism, and doesn't rely on scripting (which in this case is not 
> important, but...).
>> For example, is there a UA that would render MathML, and support 
>> scripting,
>> but not respond correctly to .hasFeature("org.w3c.dom.mathml", null); ?
> Yes, Firefox 2.0.  It does support XHTML+MathML, but mysteriously claims 
> not to [1].  In this case, for the sake of providing scripted 
> implementation extensions/fallbacks, this is as bad as not supporting it 
> in the first place, and possibly even worse, because the results will 
> now be unpredictable.

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

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.  I think the same can be said for MathML... 
while the math presented cannot not be dynamic, it can at least depict 
the formulae, and do so with a semantically rich underlying structure. 
(As a side note, I think that SVG is more in need of this dynamic 
interactivity, since it's used for Web apps... but then, maybe full 
MathML could be used for technical Web apps that are beyond my ken.)

So, the question becomes, does Firefox meaningfully implement MathML? 
Clearly, hasFeature() can't answer this question.  It doesn't say 
whether or not the UA renders MathML.  So, hasFeature() is not very 
useful if the point is to decide whether or not to invoke a script-based 
rendering implementation.

> Of course, .hasFeature is not perfect under the best of circumstances... 
> if the implementation has only partial support, or flawed support, then 
> it's unclear how it should reply.  SVG partly solves this by having lots 
> of featurestrings, but it doesn't account for flawed support.
> I'll keep trying to come up with a better solution, but it's a hard 
> problem.
> [1]



Received on Sunday, 15 July 2007 08:00:03 UTC