<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">but does within an attribute</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">value. JavaScript code only works in a &lt;script&gt; when the contents is</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">not encoded, but this turns the XHTML invalid if the contents is not</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">within a CDATA construct. The CDATA construct should not harm any</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">browser that does not understand it, so what is your aversion against</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">it except that you don't like it?</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">CDATA is not part of HTML. It's part of XML and we serve as text/html</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">which means it gets treated as HTML. It's just plain wrong.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Second, it breaks as soon as somewhere in a script is ']]&gt;' lets say</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">for XML parsing or whatever. For the person this happens this will</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">mean real pain. It's not a solution, it just appears to works in some</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">cases.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>See <A href="http://javascript.about.com/library/blxhtml.htm">http://javascript.about.com/library/blxhtml.htm</A><BR></DIV><DIV>This article seems to say that CDATA should be used in XHTML for</DIV><DIV>javascript. XHTML is what is targeted by Seaside anyway.</DIV></DIV><DIV>Also, I believe that the w3c html 4 spec mentions CDATA.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Finally, I found out that the mistake was also in SeasideAsync itself</DIV><DIV>which was not properly encoding the scripts produced by Scriptaculous.</DIV><DIV>So I changed SeasideAsync to enclose the scripts within a CDATA</DIV><DIV>without the comment constructs. The comment construct is not used</DIV><DIV>because SeasideAsync callbacks respond with a 100% well-formed</DIV><DIV>XML document (including the &lt;?xml . . . ?&gt; header) and the CDATA</DIV><DIV>cannot be parsed when it is polluted by the comment construct.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>My initial tests indicate that Scriptaculous scripts can now be generated</DIV><DIV>from within SeasideAsync callbacks. Who is going to try a SeasideAsync</DIV><DIV>live request from within a Scriptaculous callback ? How deep can we</DIV><DIV>nest the SeasideAsync and Scriptaculous callbacks ?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Cheers,</DIV><DIV>Michel.</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>