Re: An HTML language specification

On Thu, Nov 20, 2008 at 10:49 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

I agree, and I think it's great that this work has been done so that
the meaning of some of those documents can be understood by the world
at large, rather than only by specific implementations.  As I've said
before, I'm a believer in the objectives of the HTML 5 effort.

Once a document.write() occurs, from my POV you've got a brand new
HTML document with a different meaning than the one it "replaced".
Someplace else other than the language specification, you could
specify the exact state machine that describes how a processor manages
the transition between these two documents.

So you wouldn't require two parsing specs AFAICT, just one parsing
spec and a state machine.

>
>> 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.)

I assume this is a duplicate of the question I just answered in my
previous email.

Mark.

Received on Thursday, 20 November 2008 16:09:27 UTC