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

MathML entities don't degrade gracefully

From: Henri Sivonen <hsivonen@iki.fi>
Date: Thu, 24 Apr 2008 16:28:49 +0300
Message-Id: <596BB2C3-31BD-468D-BAE2-7CCBB9078BB1@iki.fi>
To: HTML WG <public-html@w3.org>, Public MathML mailing list <www-math@w3.org>

I think the inclusion of the MathML entities in HTML5 regardless of a  
MathML context violates the Degrade Gracefully design principle of the  
HTML WG. The entities don't add anything to the expressiveness of the  
language: anything that you can express with the entities you can also  
express with numeric character references or by using UTF-8 directly.  
However,  when an author uses entities that have not been  
traditionally supported by HTML, the rendering of the document in  
legacy user agents will be worse than in the situation where numeric  
character references or direct UTF-8 is used.

Could we get away with not supporting the MathML entity set in text/ 
html, considering that MathML subtrees are expected to be generated by  
converter software anyway?

As for application/xhtml+xml, the situation is even worse. DTDs don't  
work on the Web[1] and are mostly useless legacy. So far, HTML 5 has  
encouraged DTDlessness for XHTML5--and rightly so. Using the MathML  
entities in XML requires a doctype, because otherwise the document  
would be ill-formed. Browsers won't fetch a DTD based on the doctype,  
so we need to consider existing magic public IDs and potential future  
public IDs. Either way, the situation will be bad from the point of  
view of the Degrade Gracefully design principle:

When an old magic public ID is used, Firefox renders the right  
character, Safari shows an XML parse error and Opera renders a  
placeholder that looks like an entity reference.[2]

When a future public ID is used, Firefox shows an XML parse error,  
Safari shows an XML parse error and Opera renders a placeholder that  
looks like an entity reference.[3]

The result in Opera is bad in application/xhtml+xml although no worse  
than in text/html. In Safari, MathML entities in application/xhtml+xml  
are dramatically user experience-breaking in both public ID cases. In  
Firefox, using an old magic public ID would work, but trying to  
introduce *any* new public ID *ever* would lead to a dramatically bad  
experience in old versions.

Wouldn't it be better to just say "No" to the MathML entities on the  
Web and ask MathML generators to produce Unicode directly? (The few  
people who write MathML by hand are probably proficient enough to  
parse with DTD and re-serialize without DTD at their end before  
sending the re-serialized document over the public network.)

[1] http://hsivonen.iki.fi/no-dtd/
[2] http://hsivonen.iki.fi/test/moz/math-entity-known-dtd.xhtml
[3] http://hsivonen.iki.fi/test/moz/math-entity-unknown-dtd.xhtml
-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Thursday, 24 April 2008 13:29:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:54 UTC