[xsl] xsl on safari?

Subject: [xsl] xsl on safari?
From: "Birnbaum, David J" <djbpitt@xxxxxxxx>
Date: Wed, 22 Jun 2011 19:10:28 -0400
Dear xsl-list,

Thanks to those who offered suggestions in response to my original inquiry.
They didn't work, alas; a report follows.

Short version:

1. Still no luck in fixing the problem.
2. Since I needed to get the site working, I gave up and changed the links to
point to pregenerated (server-side) html.
3. The raw xml files and the xsl are still there, in case anyone reading this
has better luck than I in figuring out what's going wrong. The links are
4. While getting the site working was an immediate practical goal,
understanding what went wrong is also important. If the answer is that I can
never rely on client-side xsl transformations in Safari because it's a
mysterious browser bug, I can live with that, but if there's a reason that
these particular files are problematic, discovering that would be a better

Longer version:

The change Andrew suggests below does cause some of the xml files at
http://aal.obdurodon.org that were broken previously to display correctly in
Safari, but not all, and it also breaks files that previously were displayed
correctly. I noticed similar behavior when I tried tinkering with the content
of the files; commenting out, say, a stylesheet link would make the problem go
away for some files but also appear suddenly with others that were previous
okay. It could also change the specific text of the error report.

That tinkering with the xml files (in a small way that shouldn't have made a
difference) had an effect (even if an inscrutable one) made me wonder whether
there might perhaps be a Unicode problem, but the files 1) all pass xml
well-formedness (as well as validation in <oXygen/>, which shouldn't happen if
they aren't legal Unicode), 2) all report themselves as "XML 1.0 document
text" in response to "file filename" (where filename is the name of the file),
and 3) none seems to have a BOM (silence in response to grep -rl
$'\xef\xbb\xbf' .). xmllint (version 20626) generates a warning on the
xml-model link to the Relax NG schema in the third line of each file, which I
used to edit the files with validation in <oXygen/> (the warning is
xmlParsePITarget: invalid name prefix 'xml'), but Saxon doesn't even generate
a warning (except for the one about using an xslt 2 engine with an xsl 1
stylesheet), and commenting out those lines did not make the problem go away
(although it did make xmllint stop complaining).

What puzzles me most about this is that I don't understand why some files in
the project seem to cause problems while others created with the same schema
with what to me looks like comparable structure and content don't-- all the
more perplexing in that which files prove objectionable seems to change (in
both directions) with small edits that shouldn't have any effect. And while
it's comforting to my vanity to think that what I'm seeing isn't the result of
user error, at least with user error I could learn from the mistake and fix
the problem--never mind that if this really were a browser bug, how could I be
the only one who has been bitten?

In any case, the links in the left column at http://aal.obdurodon.org now
point to pregenerated html versions, all of which are displayed correctly in
Safari. Anyone curious enough to try to troubleshoot the problem can see the
xml counterpart (with the stylesheet applied client-side) by clicking on the
html link and then replacing the "html" at the end of the url with "xml".
Curiously, some of the ones that work have slightly different white-space
handling depending on whether saxon generated the html on the server or
whether it's being produced client-side in Safari, which is to say that when
the Safari xslt engine does perform the transformation, it generates
white-space different xml than saxon. I haven't looked into the details of the

Suggestions welcome, and thanks again to those who already took a look!



>> Windows 7, and also in Safari on an iPad and Firefox in Linux.
>> It breaks in ways I can't figure out >in Safari on MacOS and Windows.
> It does look like a bug in the browser...
>I think you can work around it by changing your <p> to <div>s here:
>    <xsl:template match="p" mode="text">
>        <p>
>           <xsl:apply-templates mode="text"/>
>        </p>
>    </xsl:template>
>    <xsl:template match="p" mode="text">
>        <div>
>           <xsl:apply-templates mode="text"/>
>        </div>
>    </xsl:template>

Current Thread