> On Jan 15, 2015, at 7:25 PM, Dimitri Glazkov <dglazkov@google.com> wrote: > On Thu, Jan 15, 2015 at 6:43 PM, Ryosuke Niwa <rniwa@apple.com <mailto:rniwa@apple.com>> wrote: > When an author imports a ES6 module, we don't create a fake object which gets resolved later by rewriting its prototype. > > These are two completely different things, right? In one situation, you are dealing with HTML Parser and blocking thereof. In another, there's no such concern. How are they different at all? I have a hard time understanding how differentiating DOM objects from other ES6 builtins will fit your stated design goal to explain the Web platform. If we are implementing the HTML parser as well as the entire DOM in JavaScript, why wouldn't we just use constructors to create DOM nodes? If your concern is that it would block the rendering of the page, then we can create a fake element that then gets later replaced. Any script that needs to store the reference or attach event listeners could simply wait until custom elements dependencies are resolved or observe DOM mutations in the document. After all, if authors are storing node references or attaching event listeners prior to DOMContentLoaded, then they must, by definition, need to deal with HTML parsers adding more nodes. If your concern is that authors must wait until other scripts that define custom elements are loaded even after DOMContentLoaded is fired, then I'd say that's not a problem UA should be solving only for custom elements. This problem exists for any set of mutually dependent asynchronously loaded scripts of at least size two or greater. This is a problem Hixie is trying solve to with "needs" attribute in his propsal to solve the script/resource dependency problem [1]. [1] https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0012.html - R. Niwa
Received on Friday, 16 January 2015 21:15:00 UTC