Re: Exploring new vocabularies for HTML

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.


-- 
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/

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