> >> 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, </script> 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. > > <script> > x = 2; > document.write('<script>x = 3;<'+'/script>'); > alert(x); > </script> > > but can this happen with innerHTML? Since </script> doesn't do anything in innerHTML, document.write can't happen from innerHTML. > Another thing I would like to understand is how real sites use > document.write(), especially cases which are performance-sensitive. Gecko whines to the developer console when document.write() invalidates speculations. When I tested the whine during Firefox 4 development, real sites didn't tend to trigger the whine, so that class of performance-sensitive use should be rare. (Though you could add telemetry!) > It > seems like such an obviously bad API compared to DOM manipulation, but I > gather it's still widespread. How often is the target the current document > vs. an iframe? I don't *know*, but I'm fairly confident that many times the ad iframes themselves are document.written by the top-level document. > > 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 <script defer> is sad (and Gecko gets it wrong) and <script async> interaction with the document's load event is sad. Other than that, I don't think there's anything unobvious going on between script loading and the document life cycle. (Assuming that we count parser-blocking scripts as obvious at this point.) -- Henri Sivonen hsivo...@mozilla.com _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
