It does seem complicated to hide the CDATA section... but it is
necessary if you have invalid XML characters in your javascript code
and do not wish to escape them individually.
No, XSLT would do this automatically, doing it differently in xml or
html output.
This took me a bit to get:
If output is set to html and remove the script template, then XSLT
(saxon at least) does not escape the output. I still need to escape
the input or enclose it in a CDATA so that the input is well formed
XML. But the output is unescaped as required. So I now understand
what you meant by not using the CDATA in the output. (One limitation
may be that you can't process it as XML again because the output
content is not escaped.... unless you happen to have an easy way to
convert the HTML back to well formed XML. Or have an XSLT processor
that can use an HTML parser.)
But if the output is set to XML, then it does seem necessary to use a
javascript comment on the CDATA because even though the output is set
to strict XHTML, the browser I tried (firefox) doesn't seem to
understand CDATA in the script element. Hence the complicated
workaround of putting a javascript comment in front of the CDATA. I
wished browsers would just understand CDATA when the doctype is xhtml
(ie XML).
So I like the idea of just not using the CDATA and using html output
(even if doctype is set to XHTML). But it still seems to have some
weaknesses.
This seems to be a common question over the years. And there is lots
of advice to be found in books like Jeni Tennison's Beginning XSLT,
and of course google. But after experimenting and understanding your
comment, I still feel unsatisfied with the possible solutions for
inline javascript. (Moving the javascript to an external file as
Andrew mentioned seems to be ideal.) Can anyone recommend a good
article that compares/contrasts techniques for dealing with inline
javascript in XML documents - such that most browsers can interpret
it?
Darcy
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--