W3C home > Mailing lists > Public > www-math@w3.org > November 2005

Re: Browser Sniffing for MathML

From: Bruce Miller <bruce.miller@nist.gov>
Date: Wed, 23 Nov 2005 14:08:37 -0500
Message-ID: <4384BE35.1050507@nist.gov>
To: Mikko Rantalainen <mikko.rantalainen@peda.net>
CC: www-math@w3.org

Mikko Rantalainen wrote:
> Bruce R Miller wrote:
> 
>> Hi all;
>>  I'm working on a project where both MathML and math images will
>> be available, but the selection _really_ needs to be automatic;
>> a `gateway' page, or similar, would be extremely awkward; standard 
>> `content negotiation' doesn't really see mathml support....
>> So, I'm apparently stuck with browser sniffing.
>>
>> I suppose most who've thought about it have encountered the
>> "^Mozilla/5.*" and "^.*MathPlayer.*" patterns, but they really
>> aren't quite right (many versions of Mozilla w/o MathML, esp
>> Mac, until just recently;  does MathPlayer 1 get matched?....)
> 
> 
> I'm currently looking for "MathPlayer 2.0" and "Gecko/200[567]" but it 
> really depends on what kind of support you're looking for. You might 
> want to add "Camino.*MathML-Enabled".

Ah, yes, that should help! Thanks!
I'll look into working with those.

> Mozilla/Gecko does supports MathML in most cases but Mozilla/Gecko 
> doesn't include all the required fonts. It correctly reports to user if 
> he is missing some fonts, but for a casual user that isn't good enough. 
> The same applies to even MathPlayer, just to lesser extent. For example, 
> MathPlayer doesn't include fonts for &notni; or &nsup; If you're sure 
> that the formulas you're trying to display render correctly with just 
> MathPlayer installed, then checking for it /should/ be safe. Except that 
> MSIE 6.0 / Windows XP allows user to disable the MathPlayer in Plugin 
> Manager (IIRC) and disabling the plugin doesn't remove the "MathPlayer" 
> string from user agent. So you cannot _really_ trust to that either!

Yep, fonts is a bit sticky.  I'm not aware of any way of determining
that from the server or client side javascript.   So, we'll be stuck
with having an easy-to-find (for those that need it) but unobtrusive
(for those that don't) link to "How to fix your browser" or something...

I'm most worried about the naive user that won't know how to install
plugins and fonts.  For those clever enough to disable the plugin,
they'll just have to be clever enough to reenable it! :>

> I provide an option to force MathML on regardless of detected user agent 
> and another option to force display of images regardless of detected 
> user agent.

Yeah, I've been wondering about that.  Cookies would be a mechanism
(although we have strict restrictions on cookies).
What I'm working on is a reference work where people should be able
to link directly into any point within the site.
This makes gateway pages awkward, and also `infecting' urls
with the format choices is also very undesirable.

> In an ideal world, user agent would list supported technologies in 
> "Accept:" HTTP header and the server could just check if 
> application/mathml+xml is accepted. 

Certainly this is what the Accept header should solve, but
I think that specific proposal can't really work in the long run.
It would be nice if some standard for "Composite documents" would
help, but I'm getting pessimistic about that.

The problem is with formats that are most likely to be components
within a larger document --- we've got MathML and SVG already,
and others will likely come ---  If every combination of
xhtml + mathml, xhtml + svg, xhtml + mathml + svg, ...
has to be covered in the Accept header, it's doomed.

OTOH, with the right re-interpretation it might be workable.
Suppose, for example, a browser claims to accept
    xhtml+xml, mathml
(the corresponding mime type, of course)
If we could interpret that to mean that it would accept
xhtml with embedded mathml, but not with embedded svg,
then we'd have a solution.
But apparently, some are afraid to even add the single
mathml to the accept...

Thanks for the links below; I was aware of some, but a
lot was new.  It's sad to be _soo_ close, and not quite there!

> The bottom line with MathML is that 
> the user agent really should be able to display pretty much all of 
> unicode but there isn't a single font anywhere that would contain all 
> the required glymphs.
> 
> URLs the check:
> https://bugzilla.mozilla.org/show_bug.cgi?id=109825
> https://bugzilla.mozilla.org/show_bug.cgi?id=124709
> https://bugzilla.mozilla.org/show_bug.cgi?id=125682
> https://bugzilla.mozilla.org/show_bug.cgi?id=201195#c19
> http://golem.ph.utexas.edu/~distler/blog/archives/000309.html
> 
> And the reason Mozillas has not fixed this issue? They're afraid that 
> the "Accept" header could end up taking too much space and slowing down 
> modem users:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=309438
> https://bugzilla.mozilla.org/show_bug.cgi?id=201195
> 


-- 
bruce.miller@nist.gov
http://math.nist.gov/~BMiller/
Received on Wednesday, 23 November 2005 19:06:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:58 GMT