Re: Recognizing xhtml under text/html

>Henri Sivonen <henris@clinet.fi> writes:
>
>> >There is a serious roadblock for the use of MathML in web pages
>> >arising from the differing expectation of user agents in regard to
>> >the HTTP content-type for a web page with such content.
>>
>> Which user agents have which expectations?
>
>I was refering to a plan for portable documents that had received
>discussion chez mozilla much earlier this year.  That plan involved a
>user agent and a third party plugin specific for MathML.  For that to
>work the XHTML+MathML document would require a small amount of baroque,
>but legal, markup to provide hooks for the plugin and the object must be
>served as text/html.  AFAIK no implementation has been released.

I don't think it would make sense to increase complexity in order to cater
for  ugly ad hockery--especially if no implementation has been released.

Of the old browsers with some kind of plug-in architecture, Netscape, Opera
and Mac IE, AFAIK, can't provide arbitrary document subtrees as data for
plug-ins. Is this all about "supporting" the "XML data island" stuff in
Windows IE? "XML data islands" inside text/html soup are already considered
harmful.

>> How would HTML extended by MathML be parsed?
>
>Probably not well.

I think that's a reason enough to not endorse MathML as text/html.

>A content provider following this migration path
>might want also to provide TeX source or an anchor to an image (rather
>than an inline image).
>
>But, as an example in answer of the question: see the browser lynx.

How would sending MathML content to Lynx be useful? Lynx doesn't how to
display MathML. The result wouldn't be accessible--just a broken rendering.

>And please don't forget that many content providers are now by site
>law required to provide *accessible* content.

How would dumping MathML as text/html promote accessibility? If MathML
source is fed to a text/html user agent, the result is a broken rendering
that is useless for determining the mathematical meaning.

Mozilla and Amaya work for people who can see. As I understand it, you are
referring to accessibility for users who can't read math visually. Until
someone produces an aural or tactile user agent for XHTML + MathML, I think
the accessible solution is explaining the math as plain text and having
that rendered in braille or read aloud. (If/when someone does produce an
aural or tactile user agent for XHTML + MathML, I think it is safe to
assume it can receive text/xml.)

>The proposal is about flexibility for content providers.
>
>> With Mozilla and old non-math browsers, this effect can already be achieved
>> using Accept header-based content negotiation to decide between
>> application/xhtml+xml (or text/xml) and text/html on the server side.
>
>As a content provider I'm just not going to provide dual html
>resources in addition to pdf.  If I must choose between text/html and
>application/xhtml, then it's going to be text/html until I estimate
>that 75 % of my readership is fully ready for application/xhtml.

I think adding complexity to the type determination would only further
hinder the implementation of MathML. Requiring support for MathML as
text/html would certainly be a problem for Mozilla.

I think the MathML would be better promoted by helping to get Mozilla's
MathML implementation into a shippable state and lobbying Netscape to ship
it by default in Netscape 6.5 and by lobbying university IT depts to
install MathML-enabled browsers as the default browsers on computers in
university labs.

>I've never been impressed with forms of robotic content negotiation,
>even if they manage to penetrate caches, proxies, and firewalls, that
>obstruct the relationship between content provider and user.

In what way?

--
Henri Sivonen
henris@clinet.fi
http://www.hut.fi/u/hsivonen/

Received on Thursday, 20 December 2001 06:35:48 UTC