- From: Bruce Miller <bruce.miller@nist.gov>
- Date: Wed, 16 Apr 2008 13:22:54 -0400
- To: William F Hammond <hammond@csc.albany.edu>
- Cc: whatwg@whatwg.org, public-html@w3.org, www-math@w3.org, www-svg@w3.org
William F Hammond wrote: > 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). Perhaps this isn't the place to restart the whole "Why XHTML Failed" debate, but I think the reason is more related to the point that Bill is raising here, and the fact that a critical user agent didn't buy-in to the application/xhtml+xml approach. In the end, there wasn't any practical way for authors to take up xhtml, or enough reason to, since most people wouldn't see it anyway. > 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. And the end result, for those who would like to serve math, is that the _server_ ends up having to Sniff the browser to determine what it should send --- a dubious improvement. > 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"? I would be interested in this revisiting, as well. But, I reluctantly have to point out that none of it will work (nor even the extensions of HTML5 over HTML) without certain, um, critical buy-ins. Where does this stand? > What obstacles to this exist? > > -- Bill > > -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/
Received on Wednesday, 16 April 2008 17:24:20 UTC