W3C home > Mailing lists > Public > public-html@w3.org > March 2008

Re: Exploring new vocabularies for HTML

From: Bruce Miller <bruce.miller@nist.gov>
Date: Mon, 31 Mar 2008 13:17:59 -0400
To: Anne van Kesteren <annevk@opera.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, David Carlisle <davidc@nag.co.uk>, ian@hixie.ch, public-html@w3.org, www-math@w3.org
Message-id: <47F11CC7.4010801@nist.gov>

Anne van Kesteren wrote:
> On Mon, 31 Mar 2008 08:43:21 -0700, Bruce Miller <bruce.miller@nist.gov> 
> wrote:
>> The proposal seems to be something like:
>> an HTML5 page with MathML-ish stuff in it.
>> The math in the _text_ of the page (1) emphatically
>> does not have the MathML namespace, (2) may have omitted
>> end tags, (3) doesn't have empty elements marked as <tag/>,
>> (4) may have attribute values that aren't quoted,
>> (5) may be limited to exclude <semantics> and named entities,
>> (6) and may in the extreme case, even omit tags for token
>> elements (<mo>,<mi>,<mn>).
>> Did I miss anything?
> I don't think it was proposed that declaring xmlns on the <math> would 
> be disallowed. Just that it would not have any effect. The same goes for 
> the other parts of the proposal I think. That is, you may mark empty 
> elements as <tag />, you may quote attribute values if you want, etc. I 
> would also expect named entities to be included.

So, Classic MathML, provided it didn't use namespace prefixes,
I assume, would be valid to embed in HTML5?
That would be good, as it would solve the problem
of synthesizing HTML5 + externally generated MathML
outside of the browser context.
[And presumably similarly for SVG]

It is doubly-good if browsers were required to
export the MathML as XML, since then that could
be dropped directly into HTML5 w/o being reserialized
in its HTML5 form.

>> OTOH, even in the more extreme case, there's no
>> reason the DOM in the browser created by the HTML5
>> parser would be any different than the DOM that
>> would have been created by an XML parser parsing
>> Classic MathML.
>> Correct?
> I think the answer here is yes, though it's not entirely clear to me 
> what the "extreme case" refers to.

"Extreme case" was refering to optional mo/mi/mn,
that is some sort of math-parsing.
>> Would this actually be a _requirement_ in the HTML5 spec?
> The HTML5 specification would dicate what input leads to what output. So 
> I think the answer is yes, if I followed you correctly. :-)
>> Clearly, such a DOM could be serialized as
>> either Classic MathML or HTML5-MathML.
> Right.
>> [...]
>> Requiring every MathML importer to include an
>> HTML5 parser, and every MathML exporter to
>> include an HTML5 serializer just seems like
>> a quadratic version of the old joke:
>>   "Now you've got _two_ problems".
> Well, if we want MathML in text/html we'll need to have some amount of 
> syntax differences. So we'll always have this problem. I would expect 
> that over time the tools will support both serializations, but also that 
> browsers provide UI features to make this task easier. I don't expect 
> HTML5 to mandate any one of those UI features though.

Are you referring to the exporting of MathML as XML
a not-necessarily-mandated "UI feature" ?
That seems really bad to me.
It forces all tools to support 2 "standards" instead of one.
Some tools may eventually support both, but for a long time
we'll have taken a large backwards step.

Besides, if, as you say, MathML as XML would be allowed
in HTML5, there'd be no need for a browser to
export the HTML5 serialization.

Received on Monday, 31 March 2008 17:18:58 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:31 UTC