Re: Exploring new vocabularies for HTML

On Sun, 30 Mar 2008, David Carlisle wrote:
> 
> Well first we need to make sure that "MathML in HTML" bears some 
> resemblance to MathML, which is something that you seem to be suggesting 
> is most definitely not the case. If the Markup language is 
> unrecognisable as MathML it makes no sense to ask if the error behaviour 
> is the same.

Assuming that MathML is integrated into HTML, the MAthML fragments in HTML 
will most definitely be the same kind of DOMs as you would get from 
strictly XML MathML. The suggestions I have made regarding parsing are 
purely syntactic and have no effect whatsoever on the resulting DOMs.


> If you think <math> 1 + 2</math> should produce a fixed up mathml dom 
> why not make <ul></li> optional and just say people can do
> 
>   * aaa
>   * bbb
> 
> as implemented in many wikis.

That would actually be a really good idea if we were designing lists from 
scratch. Unfortunately backwards compatibility leads us to not do this. In 
the case of mathematics, we get the same level of backwards compatibility 
either way, so it seems like the cleaner, easier to type syntax is the 
better option.

To put it bluntly, raw MathML is too verbose. I can't really see importing 
even just Presentational MathML into HTML if we require authors to type 
every last <mn>, <mi>, and <mo>. Anything we can do to make the language 
more maintainable will go a long way towards arguing for MathML over the 
alternatives.


> There has been a lot of press recently on the desirability of reusing 
> existing standards. You seem to be suggesting that the W3C of all 
> organisations just abandons its 10+ year investment in devising a markup 
> for mathematics that is now supported by a large range of mathematical 
> and general editing software as well as web browsers, and replace it by 
> something completely different.

Anything we do that puts MathML into text/html will, irrespective of any 
additional things we do like allow tag inference, create a new syntax. 
There is no way to avoid this. It's the same as XHTML vs text/html HTML -- 
two different syntaxes, for the same underlying DOM language and 
technology. I'm just saying that while we're screwing around with the 
MathML syntax for things like attribute quoting and error handling 
tokenisation, we might as well go further and make the syntax more human 
friendly.

Please don't assume that we can ever put the XML version of the MathML 
syntax into text/html without immediately and irrevocably creating a new 
syntax. It's not a new language, and the majority of the "10+ year 
investment" is reusable in this world, but it does mean that _parsers_ 
will need to adapt if they want to support the new language, irrespective 
of whether we go ahead and make any other changes to the syntax.

By the way, syntax is a minute part of any MathML processor today. I 
imagine most if not all MathML processors actually just use off-the-shelf 
XML parsers. There is already a growing set of off-the-shelf HTML5 
parsers, and there's no reason to believe that those wouldn't grow to 
support this MathML proposal, which would lead to the MathML tools being 
able to just swap out their XML parser and put it an HTML5 parser and 
recompile, with very little effect on the rest of the application.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 31 March 2008 01:59:14 UTC