Re: Supporting MathML and SVG in text/html, and related topics

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