Re: [dev-servo] HTML parsing alternatives

[James Graham]

On 07/03/14 07:13, Henri Sivonen wrote:


So part of the difficulty of document.write comes from the fact
that it has to interact with the script loading / document
lifecycle. Therefore it's going to be hard to get those parts of
(any) parser right until we actually implement a more correct
model of document loading. Ideally the two things would be
designed concurrently so that there isn't an impedance mismatch
between the parser and the loading code.


That makes sense.  What should I read to start understanding the
design requirements?


If I understand correctly what this is referring to, the short
version is that DOMContentLoaded interaction with 

Re: [dev-servo] HTML parsing alternatives

[Henri Sivonen]

> >> I think the biggest unknown is memory management.
> >
> > Is this the only thing that's blocking compilation
> 
> Unfortunately it's not.  Some other problems I ran into:

OK. It looks like writing a new parser directly in Rust (possibly using a 
translated Tokenizer.java as a tokenizer starting point) is the sensible way 
forward. I'm sorry about wasting your time with the translator.

> > However, it's probably a good idea to design for a code path without the
> > off-the-main-thread (or I guess task in Rust) overhead for innerHTML. See
> > https://bugzilla.mozilla.org/show_bug.cgi?id=959150#c10
> 
> Perhaps we can put the "create tree op" methods in a trait, and have one
> implementation which just applies them directly.
> 
> Do we need to do script-initiated parsing in the script task in all cases? 

No,  does nothing in the on-the-main-thread case.

> I
> was imagining that (similar to COW DOM) we could let the script continue
> until it touches the DOM again.  For document.write it seems impossible due
> to e.g.
> 
> 
> x = 2;
> document.write('