- 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