- From: William F. Hammond <hammond@csc.albany.edu>
- Date: 13 Dec 2001 08:23:28 -0500
- To: www-html@w3.org
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. > Amaya supports XHTML + MathML as > text/xml and application/xhtml+xml. And also text/html including text/html with the (so far unrecognized) profile parameter. > How would HTML extended by MathML be parsed? Probably not well. 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. And please don't forget that many content providers are now by site law required to provide *accessible* content. Images must be dropped except as alternate information. 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'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. Paul Lindner's idea for gopher+ was much better. (And didn't I see that as a fallback in a demo somewhere?) -- Bill
Received on Thursday, 13 December 2001 08:36:42 UTC