Re: An HTML language specification

Mark Baker wrote:
> On Thu, Nov 20, 2008 at 4:43 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> Mark Baker wrote:
>>> Your definition of "go away" is implementation dependent.  Consider a
>>> (admittedly very inefficient) implementation which rewrote the byte
>>> stream and then reparsed it after a document.write().
>> This implementation would be not only inefficient but also incorrect.
>> Consider the a document being loaded in a subframe which contains:
>>
>>  <script>
>>    parent.nonIdempotentMethod();
>>    document.write("I wrote something");
>>  </script>
> 
> I didn't say that no state could be maintained between parsing the two
> byte streams.

There's no reasonable way to make this work, assuming we're talking 
about the same thing as far as "parsing".  Let's try a more interesting 
example, shall we?

   <script>
     parent.doSomeNonIdempotentProccessing(document);
     document.write("I wrote something");
   </script>

Now the parent can have arbitrary references to arbitrary nodes in your 
DOM.  If you reparse, you lose.  You could not actually do any 
reparsing, just throw away the remainder of the original byte stream, 
put in the document.write content, and then append the remainder of the 
original byte stream, but that's just modifying a byte stream in place 
by another name.  You can get the same effect by always having your 
entire byte stream (including already-parsed stuff) in memory, then 
modifying it, starting at the beginning, and basically not doing any DOM 
construction or anything else until you get to the byte offset after the 
script that did the write.  It would have to leave the entire 
already-constructed DOM in place.

But in the original context of the quote above, we have:

 >> What's an "HTML document" in your opinion? Neither the network byte
 >> stream nor the object implementing the Document DOM interface go
 >> away and get replaced.
 >
 > The document is the byte stream.
 >
 > Your definition of "go away" is implementation dependent.  Consider a
 > (admittedly very inefficient) implementation which rewrote the byte
 > stream and then reparsed it after a document.write().

(Henri and you being quoted respectively).  Sounds to me like Henri is 
correct: you have to keep state that includes at least all the bytes you 
had before and the entire DOM you've built so far.

-Boris

Received on Friday, 21 November 2008 16:15:52 UTC