- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 22 Mar 2011 20:16:55 +0100
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: public-html-xml@w3.org
On Feb 10, 2011, at 18:49 , Henri Sivonen wrote: > Robin Berjon wrote: >> Hmmmm, why would you want EXI-compressed HTML to be treated as XML on >> the other end? > > To avoid defining how document.write() works when it writes something that's not a balanced subtree. Given that this is defined for HTML, what would be the exact cost? >> I would think that precisely the value it could be >> bring would be to behave as if it were simply an encoding of HTML. >> Content-Type: text/html\nContent-Encoding: exi. > > 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? I would assume that the EXI decoder would be able to maintain a state rather similar to that of the HTML tokeniser and feed whatever document.write() spouts out to the real thing. I guess that I'm not seeing the specific problem, but the description of document.write() in the spec is deceptively simple. EXI is an XML technology in the same way that XMLHttpRequest is. In fact, the XML people have been adamantly clear that it's not XML from the very beginning :) It's just a tree-based compression mechanism. I know people who are looking at using it on JSON. -- Robin Berjon - http://berjon.com/
Received on Tuesday, 22 March 2011 19:17:24 UTC