On Mar 23, 2011, at 11:02 , Henri Sivonen wrote:
> On Tue, 2011-03-22 at 20:16 +0100, Robin Berjon wrote:
>>> How would you make document.write() work?
>> I take it that the issue here is only in the case in which it runs while the parser is itself running? I'd expect that for any other case, you have a tree that's an HTML DOM and you handle it just as it is. Or am I missing something?
> It's possible that I'm misunderstanding EXI.

Let's try to get rid of our respective misunderstandings then ;)

> What's the output of an EXI decoder? Byte stream? 16-bit code unit
> stream? Unicode character stream? Start tag / end tag / character data
> event stream?
> I thought the output is of the last type. Is it?

Well you can get any of the above, but if you want parsing speed you will get something like the latter yes (some form of Infoset). I can see how that requires there to be a defined interaction between an EXI parser and the HTML parser when document.write sprouts up. What I don't see, and where I would probably benefit from enlightenment (pointers welcome), is why the EXI decoder couldn't maintain the state that the HTML parser does and "simply" feed it the document.written strings.

Maybe an example would help? Does this document:


capture enough of the problem to discuss where the rub is or do we need to get fancier with multiple calls building parts of a tree or the fun involved in document.writing script elements?

Incidentally I always suspected (but never had a strong urge to fathom in detail) that document.write could be made to work in XML, just that the desire to stick to a strict interpretation of XML alongside a generally low level of interest had made it simpler to "just say no". I think that the situation with EXI is different in that 1) there's no requirement to be that strict; 2) it should encode an HTML DOM and does not need to carry XML baggage around; and 3) the performance gains are worth researching.

Robin Berjon -

Received on Wednesday, 23 March 2011 12:07:33 UTC