Re: The interpretation of script

Robin Berjon wrote:
> On Jan 19, 2011, at 21:08 , David Carlisle wrote:
> > On 19/01/2011 18:14, Robin Berjon wrote:
> >> What happens when MathML is included in HTML?
> >
> > the html5 parser specifies that you get a mathmlelement, but doesn't
> > specify that that renders as maths, so it may just be treated pretty
> > much as an unknown element, as happens in Chrome for example.
> >
> > To test if mathml is "really" supported you need to do something
> > like render an mfrac in a hidden div and use a javascript api to
> > access the rendered height and see if it is as expected.
> 
> Ouch, that's bad. Can't someone scare up a MathElement specification?
> It seems that it could prove useful, wouldn't take more than an
> afternoon to write, and would be straightforward to implement. Is
> there any reason not to do this?

The main reason against doing it is that if the use case is sniffing, it's too late to introduce a DOM interface for MathML element to address that use case, because sniffing for the interface would fail to detect MathML support in browsers that predate the interface.

But back to the Music XML case:

Note that MathML was designed not to have name conflicts with HTML. Presentation MathML even prefixes its element local names with "m" as a namespacing (with a lower case "n") measure, so Namespaces (with capital "N") don't really provide much additional usefulness. In retrospect, it would have been better never to have MathML in a separate Namespace but to have the m-prefixed local names in the same Namespace as HTML element names. Unfortunately, by the time HTML5 added parsing support for MathML, MathML was already supported in a separate Namespace. Letting it stay in its own Namespace three two advantages compared to trying to move MathML into the HTML namespace:
 1) Chameleon Namespaces are bad, and the move would have de facto created a need to support MathML as a chameleon because of existing content that uses the MathML Namespace.
 2) Politics at the W3C: There was no need to stop for years and years to debate a namespace change.
 3) Politics at browser vendors: A person tasked with taking care of the HTML parser could add support for MathML in text/html and SVG in text/html without coordinating with the people responsible for the DOM-and-above code for MathML and SVG.

Now, Music XML does not already have DOM-and-above native code in browsers. MathML and SVG were special cases. Since we know that there's no pre-existing native browser support for vocabularies other than HTML, SVG, MathML and ARIA, every vocabulary introduced into the mix from now on can go into the HTML namespace. In fact, we successfully (against the position of the TAG) got the ARIA states and properties out of yet another namespace so that they are Namespace-wise now like normal attributes and are namespaced with the "aria-" prefix without Namespaces.

The vocabulary that's next up for getting native support is XBL2. I agree with Hixie that should go into the HTML Namespace even though I disapprove the way Hixie made the change (and other changes announced at the same time) without consulting with relevant stake holders.

If we ever add native support for musical notation, I think it should be put into the HTML Namespace. Until then, I think it's OK to use whatever <script type=foo>-based notation your JavaScript-based rendering program can render onto a canvas or into a bunch of Unicode code points and CSS boxes without expecting what you publish today ever to start getting rendered natively by future browsers. Before you actually have one browser with native music notation support to test, you can't be sure what you should do to sniff for native support and you can be almost sure that whatever code you write without testing the code will be buggy.

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

Received on Thursday, 20 January 2011 09:36:43 UTC