Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

February 16, 2006

Camino 1.0

Camino 1.0 is out. And it finally joins the rest of the Mozilla family in supporting MathML.

It’s quite fast, and has a bunch of slick features1. All in all, it’s a very attractive Cocoa-based browser, a worthy alternative to Safari.

For those who are keeping track, my rule for selecting the MIME-type with which to these pages is

RewriteRule ^$ index.shtml
RewriteCond %{HTTP_USER_AGENT} Gecko|W3C.*Validator|MathPlayer
RewriteRule \.html$|\.shtml$   - [T=application/xhtml+xml]
RewriteCond %{HTTP_USER_AGENT} Chimera|Camino/0|KHTML
RewriteRule \.html$|\.shtml$   - [T=text/html]

which says that the W3C Validator, Gecko-based browsers (including Camino 1.0 and above), and IE6 (and above) with the MathPlayer plugin installed, receive application/xhtml+xml. Everyone else receives text/html. Technically, late-model versions of Opera and Safari could handle application/xhtml+xml. But there’s no point, so I don’t bother.

Update (2/19/2006):

At Zack Ajmal’s urging, I’ve shifted to sending application/xhtml+xml to all UAs with that in their Accept header. My rewrite rule is
RewriteRule ^$ index.shtml
RewriteCond %{HTTP_ACCEPT} application\/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} W3C.*Validator|MathPlayer
RewriteRule \.html$|\.shtml$   - [T=application/xhtml+xml]

This change currently only benefits users of Opera 9. But, hopefully, Safari will get fixed someday, too. The bottom line is that, if you don’t see 平和と静けさ displayed in an attractive shade of green, then your browser is — in some fashion or other — defective.

1 That’s the good news. The not-so-good news is that, like Firefox 1.5, it now contains the still-rather-crappy builtin SVG renderer. This make a mess of the SVG figures I include in various blog posts hereabouts. Notably, it

  1. Has no support for the SVG Font Module.
  2. Doesn’t support ViewPort Size negotiation.

Opera’s builtin SVG renderer, and the one in the Safari Nightly builds, have the same problems.

There’s a workaround for the second problem. Adobe Illustrator outputs SVG files which say something like

<svg  width="345" height="249" viewBox="0 0 345 249">

If one changes this to

<svg  width="100%" height="100%" viewBox="0 0 345 249">

they will scale OK in Firefox/Camino and Opera. I’ve done that with the figures here at Musings, but it’s really a bad idea. Instead, the Mozilla, Opera and Safari people should fix their SVG renderers. And, while they’re at it, they can implement the Font Module…

In the meantime, if you have the Adobe SVG plugin installed, you can disable the builtin SVG renderer by going to about:config and setting svg.enabled to false.

Posted by distler at February 16, 2006 11:41 AM

TrackBack URL for this Entry:   https://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/752



10 Comments & 2 Trackbacks

Re: Camino 1.0

Why don’t you rewrite on HTTP_ACCEPT like explained in
The Road to XHTML 2.0: MIME Types ?

I’m thinking of doing something similar to that article, but perhaps you know something I don’t.

Posted by: Morten Liebach on February 17, 2006 2:52 AM | Permalink | Reply to this

HTTP_ACCEPT

Why don’t you rewrite on HTTP_ACCEPT…?

Named Entities.

If you serve an XHTML+MathML document to an XHTML User Agent which does not explicitly support that DOCTYPE (Safari, Opera, versions of Camino before 1.0), then you cannot use named entities beyond the “safe five” defined in XML: &lt;, &gt; &amp;, &quot; and &apos;.

That means not just none of the MathML named entities, but none of the familiar XHTML named entities, like &nbsp;, either.

Personally, I’ve gone to considerable lengths to convert, programmatically, all named entities to numeric character references wherever they might occur on these pages (including in comments — try it and see!).

So it is, in my case, technically safe to send my pages as application/xhtml+xml to all XHTML UAs. But, on the off chance that I’ve screwed up, and there’s a stray &nbsp; floating around somewhere, I still send text/html to those UAs which don’t actually benefit from it.

There’s one more special case, namely IE6 with the MathPlayer plugin. The plugin doesn’t turn IE6 into an XHTML UA (the rest of the page is parsed as HTML), so it doesn’t set the HTTP_ACCEPT header. Nevertheless, it does require the page be sent as application/xhtml+xml to parse the MathML.

Since I have to browser-sniff for the MathPlayer plugin anyway, I figure I might as well browser-sniff for the other MathML-aware UAs (Gecko-based browsers and the Validator) as well.

Posted by: Jacques Distler on February 17, 2006 7:56 AM | Permalink | PGP Sig | Reply to this

Re: HTTP_ACCEPT

There is a counter-case for HTTP_ACCEPT as well, I think. Since my blog is bilingual, I use the xml:lang attribute to define the language of a particular block (and even the whole page). XHTML 1.1 does not allow the HTML lang attribute. However, xml:lang is only properly used (as, for example, to set styles using CSS language pseudo-selectors) when the page is sent as application/xhtml+xml.

Posted by: Zack on February 17, 2006 7:17 PM | Permalink | PGP Sig | Reply to this

xml:lang

Eeek! Yes, you are right. This: 平和と静けさ should appear in an attractive shade of green. If it doesn’t, you are being cheated.

There are, of course, plenty of other differences between text/html and application/xhtml+xml. But this is one that happens to be built into my CSS.

Perhaps I should consider being nicer to my Safari and Opera users.

Posted by: Jacques Distler on February 17, 2006 8:02 PM | Permalink | PGP Sig | Reply to this

Re: xml:lang

I suggest:

RewriteCond %{HTTP_ACCEPT} application/xhtml+xml
RewriteRule \.html$|\.shtml$   - [T=application/xhtml+xml]
RewriteCond %{HTTP_USER_AGENT} W3C.*Validator|MathPlayer
RewriteRule \.html$|\.shtml$   - [T=application/xhtml+xml]

What do you think?

Posted by: Zack on February 18, 2006 1:30 PM | Permalink | PGP Sig | Reply to this

Rewrite Rule

I was looking at

RewriteCond %{HTTP_ACCEPT} application/xhtml+xml [OR]
RewriteCond %{HTTP_USER_AGENT} W3C.*Validator|MathPlayer
RewriteRule \.html$|\.shtml$   - [T=application/xhtml+xml]

If no one objects, I may go with that…

Posted by: Jacques Distler on February 18, 2006 1:38 PM | Permalink | PGP Sig | Reply to this

Re: Opera and xml:lang

Yours looks good to me and is implemented on my site now. However, Opera still doesn’t seem to do anything with the xml:lang based styles.

Posted by: Zack on February 18, 2006 8:46 PM | Permalink | PGP Sig | Reply to this

Re: Opera and xml:lang

However, Opera still doesn’t seem to do anything with the xml:lang based styles.

And neither does Safari.

Since those are the only other XHTML UAs (to my knowledge) that could benefit, I think I may put off implementing this for a while …

Posted by: Jacques Distler on February 18, 2006 9:16 PM | Permalink | PGP Sig | Reply to this

Re: Opera and xml:lang

And neither does Safari.

Actually, Safari doesn’t implement the :lang pseudoclass at all.

On the other hand, according to this comment, Opera 9 does support the :lang pseudoclass for xml:lang in XHTML.

Anyway, on the off-chance it’ll do someone some good, I’ve implemented the above rules here, too.

Posted by: Jacques Distler on February 19, 2006 3:01 AM | Permalink | PGP Sig | Reply to this

Re: xml:lang

Here’s a CSS workaround:

*:lang(ja) {color:#693;}
*[xml\:lang|=ja] {color:#693;} /* text/html workaround */

You don’t want to group the selectors, because UA’s that don’t understand the pseudo-class is required to drop the entire ruleset.

Another workaround would be to somehow remap xml:lang to lang when served as text/html.

Posted by: zcorpan on February 26, 2006 11:28 AM | Permalink | Reply to this
Read the post I Give Up
Weblog: Musings
Excerpt: Making my SVG figures work in Mozilla's built-in renderer.
Tracked: August 9, 2006 10:32 AM
Read the post Camino 1.0
Weblog: Musings
Excerpt: ... and it finally supports MathML.
Tracked: July 6, 2007 5:37 PM

Post a New Comment