xsl-list
[Top] [All Lists]

[xsl] xsl on safari?

2011-06-22 18:10:44
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 below.
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 
solution. 

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 differences. 

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

Best,

David

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>

to

   <xsl:template match="p" mode="text">
       <div>
          <xsl:apply-templates mode="text"/>
       </div>
   </xsl:template>
**************

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

<Prev in Thread] Current Thread [Next in Thread>