W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: The interpretation of script

From: Robin Berjon <robin@berjon.com>
Date: Thu, 20 Jan 2011 12:46:09 +0100
Cc: public-html-xml@w3.org
Message-Id: <4FA59ADD-205F-42C0-BDA8-D038121D2F8F@berjon.com>
To: Henri Sivonen <hsivonen@iki.fi>
On Jan 20, 2011, at 10:35 , Henri Sivonen wrote:
> Robin Berjon wrote:
>> 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.

Indeed, point conceded.

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

Agreed, but that's not a concern for this TF.

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

This is essentially what motivated my earlier question about whether it would be useful to have some text documenting how to create a vocabulary that one expects to see integrated (one way or another) with HTML. XBL might, in fact, make this need potentially more pressing. I don't think that anything normative would be useful, just some guidelines to language creators. There's information about that here and there, but most of it is lore that can't be communicated well or searched for. Sort of distributed extensibility through best practices rather than a technical mechanism.

-- 
Robin Berjon - http://berjon.com/
Received on Thursday, 20 January 2011 11:46:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 January 2011 11:46:46 GMT