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

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