- From: Erik Arvidsson <arv@chromium.org>
- Date: Thu, 21 Feb 2013 11:44:41 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Dimitri Glazkov <dglazkov@chromium.org>, Alex Russell <slightlyoff@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, public-webapps <public-webapps@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Wed, Feb 20, 2013 at 11:36 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Feb 19, 2013 3:54 PM, "Dimitri Glazkov" <dglazkov@chromium.org> wrote: >> 2) Custom element constructor runs at the time of parsing HTML, as the >> tree is constructed. >> >> PROBLEM: Several implementers let me know that allowing to run JS >> while parsing HTML is not something they can accommodate in a >> reasonable timeframe. >> >> COMPROMISE: Turn constructor into a callback, which runs in a >> microtask at some later time (like upon encountering </script>). >> >> COST: Constructing an element when building a tree != createElement. >> Also, there's an observable difference between the callback and the >> constructor. Since the constructor runs before element is inserted >> into a tree, it will not have any children or the parent. At the time >> the callback is invoked, the element will already be in the tree--and >> thus have children and the parent. > > Another cost is that when these elements will exist and be reachable from > script before their constructor runs. > > In particular they wont always have had their constructor callback run when > the constructor callback of other elements in the same subtree runs. Yeah, it is clear that running at </script> is not sufficient. We need to run the constructor callback after createElement, set innerHTML and others. Basically we need a pending queue that is processed when we go from DOM impl to user code. -- erik
Received on Thursday, 21 February 2013 16:45:27 UTC