- From: Joe English <joe@trystero.art.com>
- Date: Tue, 30 Jul 1996 11:05:05 PDT
- To: www-html@w3.org
- Cc: connolly@w3.org
"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
Received on Tuesday, 30 July 1996 14:05:22 UTC