Re: Cougar DTD: Do not use CDATA declared content for SCRIPT

Ka-Ping Yee (kpyee@aw.sgi.com)
Wed, 24 Jul 1996 20:54:47 +0900


Message-Id: <31F60F07.7566@aw.sgi.com>
Date: Wed, 24 Jul 1996 20:54:47 +0900
From: Ka-Ping Yee <kpyee@aw.sgi.com>
To: Arnoud Galactus Engelfriet <galactus@stack.urc.tue.nl>
Cc: www-html@w3.org
Subject: Re: Cougar DTD: Do not use CDATA declared content for SCRIPT

Allowing scripts to be included by external reference using
a SRC or similar attribute is clearly the simplest solution,
and i'd strongly encourage this implementation.

Mixing two languages is just a generally bad idea, but since
i can see that "inline" scripts aren't going to go away --
since (i bet) nobody is going to write their scripts by
typing &lt; and &gt; entities all over the place, the CDATA
marked section solution seems best for "inline" scripts.

Joe English <joe@trystero.art.com> wrote:
>
> 2) Use <!ELEMENT SCRIPT - - (#PCDATA)> and add browser support
> for CDATA marked sections:
>
>     <SCRIPT><![ CDATA [
>       document.write("<H1>", "Foo", "</H1>")
>     ]]></SCRIPT>

Arnoud Galactus Engelfriet wrote:
>
> Good concept, but it won't work either, I'm afraid.

No.  This is not the way to look at it.  The current deployment method
for inline scripts is simply wrong, i'm afraid.

There is NO way to correctly parse existing documents with inline
scripts that scatter < and > characters all over the place.  Guessing
what is LiveScript/JavaScript and what is HTML is a parsing nightmare.

> Current browsers don't use SGML parsers, and even if we could
> get NS & MS to implement those in their next versions, all the
> old browsers would greatly barf on this.

Too bad.  The fact that it was done wrong does not imply that we
shouldn't correct this mistake, and correct it as fast as possible.

From my experience (albeit limited), actually essential and useful
JavaScript code seems quite rare; there isn't that much to change,
and the change is easy to do.

The CDATA marked section syntax that Joe English suggests above
is easy for an author to type in, easy to parse and distinguish
from the rest of the document.  The only caveat is that the author,
i believe, still has to watch out for strings like "]]>" in the
code -- but that is an awful lot better than < and > everywhere.

This really needs to be fixed, and it should be fixed now.


Ping