1

IE9 applies MSXML6 by default, where IE8 applies MSXML3. The fact that certain functionalities are off by default in MSXML6 causes trouble, in particular when loading pages like

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="test.xsl"?>
<root>...</root>

where the xslt stylesheet referred to applies embedded javascript (for example, custom extension functions).

It is possible to set DOM xslt properties in script code, for instance in Jscript: 

var xsltDoc = new ActiveXObject("Msxml2.DOMDocument.6.0");
xsltDoc.setProperty("AllowXsltScript", true);
xsltDoc.loadXML(xsltfile);

But when loading the file supplied above, IE9 loads the xslt file automatically, with default property values. And this results in a striking difference with IE8: IE8 will load the page flawlessly, but IE9 throws an error because of the default MSXML6 DOM objects property "allow xslt scripting = false". This is not true - see my answer below. The remainder of the question is thus insignificant

How can I trigger IE9 to load the file above and still allow running scripts in the xslt?

Note: I already tried the Internet Options/Security/Custom level.../Scripting/Active Scripting = Enable as suggested on msdn, but that setting was already correct.

I am hoping there is a specific IE9 processing instruction available but I guess there isn't. But maybe thre is a special stylesheet attribute that cooperates with IE9 xslt loading.
The concluson may also be that this is only possible by running a script on a main html file, where no automatic loading is done, but XML and XSLT are loaded into specified DOM objects with specified properties (like AllowXsltScript), and the output of the transformation is then loaded into the browser explicitly.

Maestro13
  • 3,656
  • 8
  • 42
  • 72
  • Just out of curiosity: Why don't you use server-side XSLT transformations? – Tomalak May 03 '12 at 14:34
  • @Tomalak I think I understand what you are pointing at - the server creating the html and sending that to the IE9 client? But it's just local stuff that I am working with so yes, that's a good hint for any future server stuff I wish to do. – Maestro13 May 03 '12 at 14:44
  • I would rather recommend using one of the several XSLT IDEs out there, including the powerful Visual Studio XML editor and XSLT execution and debugger. – Dimitre Novatchev May 03 '12 at 15:20

3 Answers3

1

I tried an example at http://home.arcor.de/martin.honnen/xslt/test2012050301.xml with the stylesheet being http://home.arcor.de/martin.honnen/xslt/test2012050301.xsl and it works fine with me and IE 9 on Windows 7. Based on that scripting is enabled even when IE 9 uses MSXML version 6 to execute the stylesheet. If you get an error there must be other reasons or there must be something particular to your code, you will need to post minimal but complete details allowing us to reproduce the problem.

Martin Honnen
  • 160,499
  • 6
  • 90
  • 110
  • actually an answer you supplied to one of my other questions led to this one: for [question](http://stackoverflow.com/questions/10222750/how-have-an-xslt-javascript-extension-function-return-a-node-set) I ran into trouble with the link you supplied on [example answer](http://home.arcor.de/martin.honnen/xslt/test2012041901.xml) – Maestro13 May 03 '12 at 14:48
  • I think I tested that example to work with IE 9 on Windows 7 and I have now tested it again, for me it works fine, it does not throw an error. In your answer to Tomalak's comment you seem to indicate you are working with local files, not with ones served over HTTP as my examples. Is that the case? I am not sure which IE setting to change for local files to be treated the same as files loaded over HTTP. – Martin Honnen May 03 '12 at 14:57
  • Well I tried both remote and local, and both don't work. So the question seems to boil down to why my IE9 version+settings don't work while yours do.... By the way no error was thrown - just an empty page. When I activated Developer tools (F12) I found that there was an error message `XSLT8690: XSLT processing failed.` research led me to the conclusion in my question - that MSXML6 default settings are the cause. By the way your new example does work in my IE9 version...and so does the first so I will recheck what happened after all that fiddling... – Maestro13 May 03 '12 at 17:07
  • I must have touched something that triggered an automatic document mode = quirks. And I noticed earlier that when you start IE9 mode (erroring) then switch to IE8 or compat view then go back, the error does not occur any more; only for new tabs it did but not any more because of auto quirks. So I can't even reproduce the error right now :-( – Maestro13 May 03 '12 at 17:25
  • I want to get to the bottom of this so I will try to touch settings again in an attempt to recreate but I wonder two things: (1) can you check whether your IE9 browser jumps to quirks mode automatically too? (2) do you know what triggers quirks mode - and what (missing?) setting that I must have had before prevents this from occurring? – Maestro13 May 04 '12 at 06:34
  • OK not sure if this covers it but from another question I reaised ( [html1113](http://stackoverflow.com/questions/10457111/why-html1113-document-mode-restart-from-ie9-standards-to-quirks) ) I think I now know what's happening. Apart from the hickup (which I still don't understand) of my IE9 version not jumping to quirks mode automatically, the deduction in my question above seems to be wrong: it is not the DOM script setting that is causing trouble; it's the doctype or meta tag which have to be used in order to force a document mode. – Maestro13 May 05 '12 at 18:23
  • See other answer for a final verdict. – Maestro13 May 14 '12 at 09:28
1

I have a web page that performs client-side XSLT using built-in browser support (in IE9, MSXML6) invoked by JavaScript. The JavaScript uses an Ajax call to load the XSLT stylesheet (a static .xsl file) from the server into an XSLT processor object variable. The XML to be transformed is in an XML document object variable created by JavaScript. The contents of the XML document is based on the value of a textarea element on the page.

The XSL transformation was working in current versions of all target browsers (Firefox, Chrome, Safari) except for IE9, which reported the error:

"Use of default namespace declaration attribute in DTD not supported."

I tried a bunch of things to no avail. Finally, on a hunch, with hairs rising on the back of my neck, I inserted the attribute:

xmlns="http://www.w3.org/1999/xhtml"

in the html element of the web page. Not in the XML document that was being transformed, but in the web page that contained the JavaScript that invoked the XSLT transformation.

The error went away. The web page now works in IE9.

(The web page also contains an XML declaration and an XHTML 1.0 Strict DOCTYPE.)

Graham Hannington
  • 1,749
  • 16
  • 18
0

I was misguided. First, it's not IE security settings that trigger quirks mode; it's the (missing) doctype. Secondly, as can be seen in xslt8690-xslt-processing-failed, the real reason for not triggering quirks for a local file is a non-zone-related IE9 security setting.

So the DOM setting plays no role whatsoever - when IE loads xml or xslt the allowXsltScript property seems to be automatically set to true.

Community
  • 1
  • 1
Maestro13
  • 3,656
  • 8
  • 42
  • 72