Re: An HTML language specification

Mark Baker wrote:
> I agree that's complex, but I don't see why script needs to be any
> more carefully defined than "This element encapsulates a script of the
> type defined by its type/language attribute".  Inside the DOM spec,
> and/or browsing context spec, or wherever, the complexities of that
> state machine you describe can be laid out in excruciating detail.

The problem is that the "how do I parse a document?" spec needs to 
somehow reference scripts.  Or it has to provide sufficiently rich hooks 
to allow script behavior to be defined independently of it (which will 
basically make it just as complex as the currently-defined parser, if 
not more so).  The alternative is to have two separate parsing specs 
(one for the case of scripts enabled, one for the case of no scripts), 
which I don't think any of us actually want.  Please do correct me if 
I'm wrong.

It's sad that we have to be able to parse things like:

   <script>
     if (something) document.write("<!--");
   </script>
   Some text
   <script>
     if (something) document.write("-->");
   </script>

but that's life.  Heck, we have to be able to parse things like:

   <script>
     document.write("<h");
   </script>1>This is a header</h1>

I don't like it; I assume you don't like it; I assume at least the 
latter document is not valid, but stuff like this is out there, and the 
parser spec needs to handle it.

> Again, I agree that is a complex interaction that needs to be
> specified carefully.  But as with the previous example, I don't
> understand why that necessitates defining the meaning of those
> attributes in terms of the DOM.

Which part of the "DOM"ness of the DOM bothers you here?  The fact that 
it's associated with JavaScript?  The fact that it's a tree model?  The 
fact that it's called "DOM" as opposed to some other name?  Something else?

(This is a serious question; I'm trying to understand the objections here.)

-Boris

Received on Thursday, 20 November 2008 15:49:49 UTC