RE: MathML-in-HTML5

> All the support forums for technologies like XHTML and 
> browsers that support namespaces are full of people asking questions about 
> namespaces and being generally confused by them

Generally speaking you can hardly find any namespace prefix in XHTML document, excluding maybe xml:lang attribute that you are not forced to use especially if it is so horrible that it forces you to develop alternative markup language ;) Morover MathML was designed in such a way that you can easily eliminated all namespace prefixes, it has only one element that plays the role of root for MathML fragments, just include one line in internal DTD and say goodbuy to explicit namespace syntax in XHTML+MathML documents.
 <!ATTLIST math xmlns CDATA #FIXED "http://www.w3.org/1998/Math/MathML">
The only issue with excluding prefixes in this way is the bug in MSIE's XML parser that does not process default attribute values properly. Other browsers understand it and place MathML is a proper namespace, so you don't need to care about namespaces.


> Compatibility with current MathML authoring and processing is neither here 
> nor there -- the proposal here doesn't affect it in any way.

What do you mean? Certain level of interoperablity is achived, we need better of course but I don't see how making markup spliting markup in two parts will improve situation.

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

> But 
> what is practically of interest is that HTML5 gives us MathML support 
> everywhere (with today's browers), and this is where what IE+MathPlayer 
> comes in the picture. 

If interoperability is a goal then XHTML is the way to go, as all current MathML implementations can handle it, but apparently not all of them can process MathML in tag soup format.

> It fully defines the parsing model 
> for HTML, whether correct or incorrect, in a way compatible with how 
> browsers handle incorrect ("tag soup") documents today.

> "Tag 
> soup" is so called because it implies that browsers don't know how to 
> handle it and so all do their own thing (which is indeed the case today, 
> but will no longer be the case if HTML5 is implemented per spec

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. And once again let me note that MathML community does not have tagsoup parsing problems today, and we don't need to go in that direction no matter whether HTML5 will specify telephathic tag soup parsing rules or not. Such a rules may be followed by UAs or may not like the tools that produce tag soup may keep it valid or may not, and 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.


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

Powered by Outblaze

Received on Thursday, 5 October 2006 09:04:33 UTC