Re: An HTML language specification

If I may cite Boris in reverse order :

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

That is my position, too : I want to see if there is
substance in these arguments.

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

In a sense, what you are doing is adding one level of complexity;
it is quite possible that there could be other levels of complexity,
but surely the starting point must be the definition of HTML 5 as
a static language (as a "serialisation", if you want to use the
current jargon).  And that is what Mike's document sets out to do.

You can then layer on that one level of complexity, by allowing
scripts to contribute content to a not-yet-loaded page, but
that can be handled in an adjunct specification : by definition,
anything that the script adds will either be, or not be, valid
HTML 5 in the context in which it is added, using the static
model above as the basis for assessing validity.

A further refinement might be that the internal model of the parsed
document (the "DOM") might also be subject to run-time manipulation;
in that case, too, a separate specification can address this issue.

What is not clear to me (and I know, to others too, though the
lack of clarity is by no means universal) is why anyone should
seek to conflate these three distinct phases, when the benefits
of keeping them distinct seem so clear.

Philip TAYLOR

Received on Thursday, 20 November 2008 16:13:03 UTC