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 <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.)
So I actually meant "document lifecycle" in the more general sense of
"process for loading documents" and specifically of the things that
ended up as the script_ tests at [1] (originally [2]); those tests
specifically cover the final execution order when document.writing
script elements. Possibly Gecko had the right design to make these
things unproblematic; it turns out this is not a universal property of
all designs. Also, I don't think any part of that can be regarded as
"sufficiently obvious" in servo since we basically don't implement any
of it :)
Getting the details of [3] right is also, as Henri points out, not trivial.
[1] http://w3c-test.org/html/dom/dynamic-markup-insertion/document-write/
[2]
https://github.com/operasoftware/presto-testo/tree/master/core/standards/html-parsing/regression/write/script
[3]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
