[17 January 2008]
So what is it about Safari and XSLT?
I write a lot of documents. I write them in XML. I really like it when publishing them on the Web means: just checking them into the W3C’s CVS repository (from which they propagate to the the W3C’s Web servers automatically, courtesy of some extremely nifty software put together by our Systems Team with chewing gum, scotch tape, and baling wire great ingenuity). No muss, no fuss. No running make or ant. Just. Check. It. In. And presto! it’s on the Web.
And mostly that works.
Actually, for the browsers I usually use, it always works. But I have friends who tell me I really should be using Safari, as it’s faster and simpler and better in ways that momentarily defeated their ability to explain — if I tried it for awhile, I would see, I think was the idea.
But Safari puts me in a bind.
I can’t use Safari as my daily browser if I can’t reliably display XML in it.
And I can’t write it off entirely as a waste of my time, since much of the time it does display XML just fine.
That is: sometimes it works. And sometimes it doesn’t. And so far I have not been able to get much light shed on when.
To take a simple example: consider this working paper I’m writing for the W3C SML Working Group. There are two copies of this document: one on the W3C server at the URI just linked to, and one on my local file system, in the directory subtree that holds stuff I’ve checked out from the W3C CVS server. All the references (to DTD, to stylesheet, to images, …) are relative, so that they work on the local copy even when I’m off the network, and so I don’t have to change them when I check revisions in.
The local document displays fine in Firefox. So does the copy of the server. Opera displays both the local and the Web copy just fine. Internet Explorer displays the Web copy just fine. I don’t have a copy of IE that can check the local copy, but I used IE for display of local XML for a long time; I’m confident it would work fine.
Safari displays the local copy just fine.
And on the Web copy? Safari gives me a blank screen.
Safari has, it seems, a love/hate relation with XML.
And that means I have a love/hate relation with Safari.
safari on windows doesn’t display anything either, even on a local copy of your file, the problem appears to be xsl:import, even if the imported file is cut down so it has no templates at all it still causes no output. changing to xsl:include seems to bring it back to life….
David: thanks for the help. I tried changing the import to an include just now on the Web copy, but before I got it to work I realized one of the templates in the top-level stylesheet calls apply-imports, so I think an include is off the table here.
On the other hand, Fabio Vitale set his student Luca Cervone to work on the problem, and fifteen minutes later received the advice “lose the DTD”. I can’t suppress the DTDs entirely in these stylesheets, because I use entities a lot, but suppressing the system identifier in both the main and the imported stylesheet seems to make Safari happier. (It doesn’t make me happy, because I haven’t gotten around to making psgml.el read XSDL schemas, so I rely on DTDs a lot. Fortunately, psgml.el supports the old SGML Open catalog spec, and I think I can make it find the right DTD using a DOCTYPE entry in the catalog.)
So thanks also to Fabio Vitali and Luca Cervone!
hmm killing the DTD was the first thing I tried, altough it didn’t seem to make any iimprovemt for me. Maybe I missed one, it wasn’t an in depth investigation:-)
Your test file on the w3c server now displays in safari on windows (but reports “1 error” somewhere on javascript? (javascript console just says “null value”)
Mostly I’ve switched over to James C’s nxml mode for emacs xml work.
Of course it also means using Relax NG rather than XSDL, but I’m sure you wouldn’t mind that:…
Hi,
The problem is that the DTD is not available at the specified URL.
So you mustn’t suppres the DTD in the Stylesheet but you must insert a DTD
declaration that points to an existent file.
Hope this comes in aid.
Ciao
Luca Cervone
Pingback: innerHTML » Blog Archive » Safari, XML and XSLT
For a really dramatic looking bug, take a look at http://sroe.home.cern.ch/sroe/test/test.xml
and try resizing the window…
yep, Shaun,
That’s pretty orible, resized it and couldn’t even work out where my window was; eugh!
writing a google map pulling in xml data, works in everything else but safari
🙁
It looks like the bugs have been removed in Safari.