W3C home > Mailing lists > Public > www-math@w3.org > October 2006

RE: MathML-in-HTML5

From: White Lynx <whitelynx@operamail.com>
Date: Tue, 03 Oct 2006 18:55:23 +0400
To: www-math@w3.org
Message-Id: <20061003145523.9912A43D78@ws5-1.us4.outblaze.com>

| Copy sent to http://groups.google.com/group/mozilla.dev.tech.mathml

 > >It does not make sense to remove 
 > >tokens from markup while preserving them in DOM (the semantic value of 
 > >tokens automatically generated by parser is zero, and not all 
 > >conversion/interchange tools operate through DOM). 
 > HTML does  this all the time. (E.g. inferred <tbody> element as a child 
 > of <table>, inferred <head> and <body> elements,...) There's nothing 
 > wrong with inferred elements ... per se. 
 One thing when you can unamboguously infer completely useless element that has no semantic value and just groups rows (tbody) and another thing is when you infer out of nowhere elements with either predefined presentation or semantic like address, or i.

 > The only problem occurs when people expect their MathML code (or, more 
 > pertinently, the software they use to generate it) to be interoperable 
 > in an XML context. 
 > >> This might also 
 > >> encourage those building HTML authoring tools to consider interfacing 
 > >> MathML (either with free or commercial plug-ins) because the XML/XHTML 
 > >> barrier won't be standing right at their face. 
 > >Once again there is no barrier, XHTML has all the functionality that 
 > >HTML has and much more. 
 > I disagree strongly. XHTML is a *huge* barrier. CMS's that reliably 
 > produce XHTML are rare to nonexistent. 
 You tend to turn simple things into rocket science. 

 > And many users don't have control over the MIME-type their pages are 
 > sent with. If they did, you wouldn't have so many RSS feed sent as 
 > text/XML (which,  unless they are plain ASCII, means they are 
 > automatically ill-formed). 
 Browsers follow Appendix F.2 of XML recommendation  (if an XML entity is in a file, the Byte-Order Mark and encoding declaration are used (if present) to determine the character encoding) not RFC 3023.

 > >The only issue is MSIE parser and as noted 
 > >above several times this issue is N/A to MathML today. 
 > Precisely. MathPlayer2 allows IE/6 to consume MathML embedded in tag 
 > soup *TODAY*. 
 Well, MSIE does not deal with MathML in any form and I am not against embededing MathML in environments other then XML (you can embed it in LaTeX if you want) but I am against turning it into tagsoup which is a different issue.

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

Powered by Outblaze
Received on Tuesday, 3 October 2006 14:55:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:38 UTC