Re: MathML-in-HTML5

> > > > In the context of HTML5 the term "tag soup" is meaningless, 
> > since > there is no UA-defined handling anymore
> >
> > Error handling comes naturally and developers are not supposed to 
> > put all resources into area that provides no real functionality. 
> > It is UA defined and I don't know how HTML5 is suupposed to 
> > change it if the UA that defines error handling today does not 
> > participate in the process and due to its share faces no error 
> > handling problems in the way others face them.
> 
> In the case of HTML5 (like in CSS, for that matter), error handling is
> *not* UA-defined -- it is strictly defined by the specification

Well, following your definition of HTML5 (= everything that is served as text/html) it is clear that HTML5 UA is everything that processes text/html. And how text/html is processes by UAs we all know.
But this is actually offtopic issue because we don't discuss here whether HTML5 is better then XHTML5 or HTML4 is better then XHTML2, or whether ISO HTML is better then  XHTML 1.1 etc. 
What we say is that having two versions of MathML will not help us to consolidate efforts, instead it will dissipate already small resources that we have today. For example your proposal breaks compatibility with MSIE/MathPlayer, compatibility which was achived only recently, it took several years for them to recognize application/xhtml+xml and give people opportunity to serve the same markup to Mozilla and MSIE. There are tools that process XML only and not HTML. But the problem is not just compatibility. The kind of differences between HTML(always add 5 if you'd like) and XHTML(5) that you use to promote MathML in HTML are minor, they are to small to justify having two versions of MathML. While fundamental differences, such as being part of extensible framework, being able to reuse other standards that are primary targeted to XML and not HTML that W3C basically abandoned several years ago, being able to easily extend/revise/depricate some parts of MathML without affecting parsers and many other issues incline us to think that we should stick to one MathML and that MathML should remain to be XML based. 



> > If all do their own thing today then how HTML5 parsing rules 
> > could could be compatible with the way how browsers handle 
> > incorrect ("tag soup") documents today.
> 
> I did a lot of extensive research before documenting the HTML5 parsing
> rules, to ensure that the common aspects, which documents depend on, were
> carried forward, while the more unique aspects, which documents did not
> depend on, were simplified and unified.

Well we don't have this kind of problems in MathML. Stuff like <mfrac><mi>1<msup><MN>5</mfrAC>+3</mrow></msup></MN></mi> is not present in current MathML documents as wellformadness restriction eliminates them automatically (it does not ensure that markup is valid, but wellformadness is enough to ensure that you have the same DOM across browsers). In addition it forces authoring tools and convertors to pay attention to what they produce, because if they will make mistake that leads to non-wellformed output it will immidiately break the page and they will have to ensure that markup that they produce is well formed by design. It is not the case for HTML authoring tools where problem can be just ignored (and is often ignored).

> > And once again let me note that MathML community does not have tagsoup
> > parsing problems today
> 
> If we go with the HTML5 route, it will continue not having such problems,

This is theory that I would not follow and it is far from reality.

> since HTML5 strictly defines how all content is parsed.

SGML defined it a long long time ago (either you follow DTD or get error message), no one followed it when implementing HTML.

> > ...at the moment I see only one UA that wants to go in this way, 
> > I don't think that others will follow it, in case of MathML tag 
> > soup at least. HTML tag soup as such may be different issue as 
> > here browsers have motivation coming from the large amount of 
> > legacy content so if HTML5 will reverse engineer MSIE error 
> > handling and document it others may find it useful, but once gain 
> > this is not an issue for MathML implementations where we lack 
> > implementations in browsers (so even absolutely valid markup is 
> > not treated properly) and are talking about specifying 
> > comprehensive error handling that people are supposed to devote 
> > time and resources to.
> 
> The parsing (and error handling) rules for the proposed math-in-HTML5 is a
> _subset_ of the general HTML5 parsing (and error handling) rules,

We don't want to inherit HTML legacy through parsing rules or otherwise.
We managed to avoid it for a price that appeared to be quite high, but it is payed already and is not refundable. Today you can serve the same XHTML+MathML to MSIE and Mozilla and use a lot of XML tools, following your proposal we will loose this and gain nothing valuable instead (more tag soup). 

> such
> that any browser that implements HTML5 parsing automatically is compatible
> with HTML5+Math parsing. 

We already use the same parsing rules for MathML and all other XML applications (I assume including XHTML5 unless you will invent something new).

> (The only requirement then is that the UA also
> implement MathML itself, so that the resulting DOM is handled per MathML
> rules.)

Yep once one implements tagsoup parser then he/she can also start implementing MathML itself. Thanks for permission. Some would go other way round and provide functionality first and then maybe error handling (and maybe not, who cares?).


-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze

Received on Friday, 6 October 2006 08:52:50 UTC