It would be great to post the solution, when you know it. I haven't really used Chrome for anything serious -- seems like a google-toy to me. Why do you need to perform XSLT client-side?
– Dimitre NovatchevJun 5 '10 at 18:35

I don't. I just thought it would be kinda neat. And I'd still like to know why some things work on Chrome, but mine doesn't. Oh, and for IE users, sorry for the atrocious rainbow styling of the page.
– EricJun 5 '10 at 18:46

12

For me Chrome can do the transformation only when opening the XML over http://, it does not work when working via file://, the xmlns-attribute does not make any difference for me.
– Jaroslav ZárubaNov 19 '10 at 9:58

Because you are logged in to Gmail, the frame loads the messages in your inbox.

The local web page reads the contents of the frame by using JavaScript to access frames[0].document.documentElement.innerHTML. (An online web page would not be able to perform this step because it would come from a non-Gmail origin; the same-origin policy would cause the read to fail.)

The local web page places the contents of your inbox into a <textarea> and submits the data via a form POST to the attacker's web server. Now the attacker has your inbox, which may be useful for spamming or identify theft.

Chrome foils the above scenario by putting restrictions on local files opened using Chrome. To overcome these restrictions, we've got two solutions:

Try running Chrome with the --allow-file-access-from-files flag. I've not tested this myself, but if it works, your system will now also be vulnerable to scenarios of the kind mentioned above.

This is true, however that was not the only cause of the problem. I've been following the "bug" report for a while now. However, I couldn't get it to work server-side either without the xmlns attribute. This might have changed in newer versions of chrome.
– EricAug 25 '11 at 10:34

4

@Eric ok this may not be an answer to your problem, but it is the correct answer to your question. judging by the comments of the visitors to this page, we can see that the answer that had been marked answer is not solving their problems. (otherwise why would they have to wade through the other 6 answers to find a solution)
– PacerierAug 26 '11 at 1:07

4

@Pacerier: It's not the correct answer to my question. My question was asking about why a pair of documents hosted on my server were not being transformed correctly. The security problem, while worth knowing, is not relevant to this particular question.
– EricSep 30 '11 at 15:45

-1 : just not true, you don't need that declaration
– PeterMay 23 '11 at 8:07

1

@Peter: it depends on your input document. The XSLT spec is pretty clear here and IE is just too forgiving. If the input is valid XHTML, it has a namespace declaration. To have XSLT locate anything in that input document, you must define the namespace. It's, however, not necessary to use the default namespace (but easiest).
– AbelJun 15 '11 at 12:49

10

@Eric: take a look at my answer, no offense, but your answer is wrong.
– PacerierAug 23 '11 at 7:35

4

This is not the answer (nor the solution, and the "..." is definitely a bit vague), Pacerier's is the correct one.
– RedGlyphSep 30 '11 at 9:07

I had the same problem on localhost.
Running around the Internet looking for the answer and I approve that adding --allow-file-access-from-files works. I work on Mac, so for me I had to go through terminal sudo /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files and enter your password (if you have one).

Another small thing - nothing will work unless you add to your .xml file the reference to your .xsl file as follows <?xml-stylesheet type="text/xsl" href="<path to file>"?>. Another small thing I didn't realise immediately - you should be opening your .xml file in browser, no the .xsl.

The problem based on Chrome is not about the xml namespace which is xmlns="http://www.w3.org/1999/xhtml". Without the namesspace attribute, it won't work with IE either.

Because of the security restriction, you have to add the --allow-file-access-from-files flag when you start the chrome. I think linux/*nix users can do that easily via the terminal but for windows users, you have to open the properties of the Chrome shortcut and add it in the target destination as below;

for referencing the XSL stylesheet) is served as "application/xml". In that case, Chrome will still download the referenced XSL stylesheet, but nothing will be rendered, as it will silently change the document types from "application/xml" into "Document" (!??) and "text/xsl" into "Stylesheet" (!??), and then will attempt to render the XML document as if it was an HTML(5) document, without running first its XSLT processor. And Nothing at all will be displayed in the screen (whose content will continue to show the previous page from which the XML page was referenced, and will continue spinning the icon, as if the document was never completely loaded.

You can perfectly use the Chrome console, that shows that all resources are loaded, but they are incorrectly interpreted.

So yes, Chrome currently only render XML files (with its optional leading XSL stylesheet declaration), only if it is served as "text/xml", but not as "application/xml" as it should for client-side rendered XML with an XSL declaration.

For XML files served as "text/xml" or "application/xml" and that do not contain an XSL stylesheet declaration, Chrome should still use a default stylesheet to render it as a DOM tree, or at least as its text source. But it does not, and here again it attempts to render it as if it was HTML, and bugs immediately on many scripts (including a default internal one) that attempt to access to "document.body" for handling onLoad events and inject some javascript handler in it.

An example of site that does not work as expected (the Common Lisp documentation) in Chrome, but works in IE which supports client-side XSLT:

This index page above is displayed correctly, but all links will drive to XML documents with a basic XSL declaration to an existing XSL stylesheet document, and you can wait indefinitely, thinking that the chapters have problems to be downloaded. All you can do to read the docuemntation is to open the console and read the source code in the Resources tab.

I don't think so. To perform the transformation, Chrome does not need to set the default namespace to XHTML namespace. To render XHTML it needs proper XHTML, of course. You are mixing things.
– user357812Jun 8 '10 at 13:45

The site referenced above is not built with XML but with XHTML. The two are not quite the same (both are XML but one is also HTML and the other is not).
– jerseyboyFeb 8 '12 at 0:38

I started testing this and ran into the local file / Chrome security issue. A very simple workaround is put the XML and XSL file in, say, Dropbox public folder and get links to both files. Put the link to the XSL transform in the XML head. Use the XML link in Chrome AND IT WORKS!

I'm unable to open a new session of Google Chrome without other parameters and allow 'file:' schema.

On macOS I do:

open -n -a "Google Chrome" --args \
--disable-web-security \ # This disable all CORS and other security checks
--user-data-dir=$HOME/fakeChromeDir # This let you to force open a new Google Chrome session

Without this arguments I'm unable to test the XSL stylesheet in local.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).