- From: William F Hammond <hammond@csc.albany.edu>
- Date: Wed, 16 Apr 2008 12:36:49 -0400
- To: whatwg@whatwg.org, public-html@w3.org, www-math@w3.org, www-svg@w3.org
Henri Sivonen <hsivonen@iki.fi> writes: > On Apr 16, 2008, at 10:47, Paul Libbrecht wrote: >> I would like to put a grain of salt here and would love HTML5 >> passionates to answer: >> >> why is the whole HTML5 effort not a movement towards a really >> enhanced parser instead of trying to redefine fully HTML successors? > > text/html has immense network effects both from the deployed base of > text/html content and the deployed base of software that deals with > text/html. Failing to plug into this existing network would be > extremely bad strategy. In fact, the reason why the proportion of Web > pages that get parsed as XML is negligible is that the XML approach > totally failed to plug into the existing text/html network effects > (except for Appendix C which lacks a migration strategy to actual XML > and amounts to the emperor's new clothes). About 7 years ago there was argument in these circles about whether correct xhtml+mathml could be served as text/html. As we all know, a clear boundary was drawn, presumably because it was onerous for browsers to "sniff" incoming content and then decide how to parse. As things have evolved, we now know that browsers do, in fact, perform a lot of triage. See, for example, "Mozilla's DOCTYPE sniffing", http://developer.mozilla.org/en/docs/Mozilla's_DOCTYPE_sniffing Especially since we are speaking about dual serialization of the same DOM and since there is relatively little use of "application/xhtml+xml" (and some significant user agents do not support it), might it not be worthwhile to re-examine the question of serving standards-compliant xhtml or xhtml+(mathml|svg) serialized document instances as either "text/html" or "application/xhtml+xml"? In other words, why not be able to serve both serializations as "text/html"? What obstacles to this exist? -- Bill
Received on Wednesday, 16 April 2008 16:37:40 UTC