SCRIPT recommendation (was:...Do not use CDATA declared content..)

Joe English (joe@trystero.art.com)
Tue, 30 Jul 1996 11:05:05 PDT


Message-Id: <9607301805.AA25730@trystero.art.com>
Subject: SCRIPT recommendation  (was:...Do not use CDATA declared content..) 
To: www-html@w3.org
Cc: connolly@w3.org
In-Reply-To: <199607300450.AAA21234@anansi.w3.org> 
Date: Tue, 30 Jul 1996 11:05:05 PDT
From: Joe English <joe@trystero.art.com>



"Daniel W. Connolly" <connolly@w3.org> wrote:
> I'm afraid I'm lost in this thread. It started with a pretty
> clear suggestion by Joe to please don't use the evil CDATA.
> 
> Unfortunately, the responses were a mixture of argument-by-assertion
> and misinformation about SGML.
> 
> I haven't found anything that I want to forward to the editors of the
> draft. I'm not likely to follow this thread any more, so folks might
> want to start new, more focused threads.


May I suggest:

(1) In the Cougar DTD, change the declaration of the SCRIPT element
from CDATA declared content to:

<!ELEMENT SCRIPT - - (#PCDATA)>

and remind authors that, as is the case with other HTML
elements, care must be taken to protect any characters in the
content of a SCRIPT element that would otherwise be misinterpreted
as SGML markup, namely < and & when immediately followed by a letter. 

(2) Advise authors that where possible, this should be done 
by surrounding the characters in question with whitespace or
by using the facilities _of the native scripting language_ 
instead of using entity references, marked sections, or other 
SGML mechanisms.


For example:

    <SCRIPT language="Tcl">
    set lt "<"; set gt ">"; set amp "&";
    puts stdout "Here's an end-tag: ${lt}/H1${gt}"
    </SCRIPT>

    <SCRIPT language=whatever>
    <!-- Don't do this: -->
    if (a<b&&c<d) { ... }
    <!-- Do this instead: -->
    if (a < b && c< d) { ... }
    </SCRIPT>


* * *


Or, hell, just stick with CDATA declared content for SCRIPT.
The number of authors who use both <SCRIPT> *and* a validator
is probably negligible to begin with, and relying on one of
SGML's most ill-designed, unworkable, and hard-to-understand
features will help make sure that it stays that way, so the
ill effects will be mostly invisible. 


> I can already see folks launching into appeals, making the same
> arguments with the same evidence, but with stronger rhetoric. That
> won't help. 

Oops, sorry :-)


--Joe English

  joe@art.com