xsl on safari?
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> **************
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format