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)

x86
Windows XP
defect
Not set
minor

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">
// &lt;!--
  script content here
// --&gt;
  </script>

But again, why would you want to do that?
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
  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 &lt;-- 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
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.
(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.
<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.
(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.