Closed
Bug 311283
Opened 19 years ago
Closed 19 years ago
JavaScript created by XSLT undefined when created in xsl:comment
Categories
(Core :: XSLT, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: gfaron, Assigned: peterv)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 (No IDN) Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 (No IDN) Firefox/1.0.6 For editing simplicity, it is often convenient for me to enclose JavaScript content within an XML comment tag: <script type="text/javascript"> // <!-- script content here // --> </script> This prevents my editor from complaining or re-indenting the code on me. To continue this practice when using XSLT, I use <xsl:text>// </xsl:text><xsl:comment><xsl:text><![CDATA[ script content here // ]]></xsl:text></xsl:comment> in my .xsl file to prevent XMLSpy from complaining about an invalid document. FireFox will not recognize or execute any code produced in this manner, though the transformed file (saved to disk from an XSLT engine) runs fine in FireFox. In order to get FireFox to run it, I need to lose the <xsl:comment/> tag, and therefore produce a less-than-ideal result. Reproducible: Always Steps to Reproduce: 1. Create a stylesheet named style.xsl. Fill it with this: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <head> <title>Dynamic JavaScript Creation</title> <script type="text/javascript"> function foo() { alert("foo() fired!"); } alert("defined without xsl:comment"); </script> <script type="text/javascript"> <xsl:text>// </xsl:text> <xsl:comment> <xsl:text disable-output-escaping="yes"><![CDATA[ function bar() { alert("bar() fired!"); } alert("defined with xsl:comment"); // ]]></xsl:text> </xsl:comment> </script> </head> <body> <input type="button" value="Call foo()" onclick="foo();" /> <input type="button" value="Call bar()" onclick="bar();" /> </body> </html> </xsl:template> </xsl:stylesheet> 2. Create a dummy xml file and fill it with this: <?xml-stylesheet type="text/xsl" href="style.xsl"?> <root/> 3. View xml document using FireFox. Actual Results: The first alert fires and the second doesn't. Also, the first function is defined (as evidenced by pressing the first button) but the second function is not found (a la the second button). Expected Results: Both alerts should have fired; both functions should be defined.
First of all, why would you want to have a comment around your script? Back in the old days it was done to prevent browsers that didn't support script from rendering the script. However there are nowadays no browsers that don't support the <script> tag. And there are *especially* no browsers that support xslt but don't support <script>. Mozilla does never execute script inside comment nodes. However when parsing HTML the contents of a <script> tag is not parsed as markup and thus no comment node will be created but rather a normal text node (this is what the html standard says to do). If you do the same in XML you'll notice that the script will not be executed since in XML contents of all elements will be parsed as markup. If you want your xslt to behave like your HTML does then do: <xsl:template match="/"> ... <script type="text/javascript"> // <!-- script content here // --> </script> But again, why would you want to do that?
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•19 years ago
|
||
As to the question of why, I have already stated the reason for doing this: It allows both the source and the transformed result to be valid XML documents, openable in validating editors. I can understand your assertion that FireFox never runs code from a DOM Comment Node object; that makes sense. And thanks for clarifying that the contents of the script tag, including the <!-- and --> are made into Text Nodes and not (official) Comment Nodes in the DOM tree; that is also helpful to know. Rather than munging the <!-- into a <-- as you've suggested, I've found that using <xsl:text disable-output-escaping="yes"><![CDATA[ // <!-- JS code here // --> ]]></xsl:text> works just as well and is more readable to me. As for the spec, I do not know if it speaks to this, I haven't figured out where to look for it. I was merely noticing that my XML which ran in Internet Explorer failed to run in FireFox. This was made more odd because the TRANSFORMED page runs fine after saving it out. It was this apparent inconsistency that was disturbing me. I hope this response is helpful to others having the same issue.
Status: RESOLVED → VERIFIED
Reporter | ||
Updated•19 years ago
|
Summary: JavaScript created by XSLT undefined when created outside of head or in xsl:comment → JavaScript created by XSLT undefined when created in xsl:comment
(In reply to comment #2) > As to the question of why, I have already stated the reason for doing this: > It allows both the source and the transformed result to be valid XML documents, > openable in validating editors. It will be valid XML no matter what. The only purpose of the comment is (and ever was) to make the script not be rendered by browers that have no idea what the <script> tag is.
Reporter | ||
Comment 4•19 years ago
|
||
(In reply to comment #3) > It will be valid XML no matter what. The only purpose of the comment is (and > ever was) to make the script not be rendered by browers that have no idea what > the <script> tag is. Okay, now this is just getting to be a flame war, but here's an example of what I mean. Suppose I have the stylesheet: <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format"> <xsl:template match="/"> <html> <head> <title>title</title> <script type="text/javascript"> alert(4 > 5); alert(2 < 3); </script> </head> <body> <p>body</p> </body> </html> </xsl:template> </xsl:stylesheet> The javascript here makes the xsl document non-well-formed. Yes, I could write the angle brackets as named-entities, but years of writing code using the same operators has made me a bit stubborn in trying to read code. Using comments around the code block allows me to use the characters that actually mean something to me.
Comment 5•19 years ago
|
||
<script type="text/javascript"><![CDATA[ alert(4 > 5); alert(2 < 3); ]]></script> is the very easy and standard way to do it. Just like you would in XHTML, as the script tag isn't CDATA like it is in the HTML DTD. http://www.w3.org/TR/html4/sgml/dtd.html#Script and http://www.w3.org/TR/xhtml1/#h-4.8
I didn't mean to sound inflammatory, I'm sorry if I did. I just want to get things on record for other people that might read this bug. Like axel said, and like you had already noticed, what you want is CDATA, that is what makes the parser behave as you want it, and like it does in HTML. The actual *comment* part used in html was just an old construct for browsers that didn't support script elements. It doesn't change how the parser behaves, especially since the text isn't interpreted as a comment at all since the contents of a <script> isn't treated as markup. This is something that has been forgotten over the years and people nowadays seem to include them more out of tradition rather then anything else. Note that even browsers like lynx does support the script element, it just doesn't support scripts. But it knows not to render the contents of the element. So you're not alone in your reasoning, we've had this exact issue filed before in at least bug 217956, bug 221862, bug 222775, and bug 271838. :) Btw, this whole discussion applies to the <style> element as well.
Reporter | ||
Comment 7•19 years ago
|
||
(In reply to comment #5) > <script type="text/javascript"><![CDATA[ > alert(4 > 5); > alert(2 < 3); > ]]></script> > is the very easy and standard way to do it. Just like you would in XHTML, as the > script tag isn't CDATA like it is in the HTML DTD. Almost. The end result here doesn't have comment tags around the script code. Therefore, if I open the transformed result in a validating editor for some reason (testing, most likely), the inequality operators there will set off an alarm.
They really shouldn't. It is valid HTML even without the "comment".
You need to log in
before you can comment on or make changes to this bug.
Description
•