- From: Dominic Cooney <dominicc@google.com>
- Date: Mon, 26 Oct 2015 11:35:24 +0900
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: Elliott Sprehn <esprehn@chromium.org>, public-webapps <public-webapps@w3.org>
- Message-ID: <CAHnmYQ_4SHtXxK=LHg7jwtEVg=KGMrjbdCLjNUR7e7NVkTipXQ@mail.gmail.com>
On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa <rniwa@apple.com> wrote: > > > On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <esprehn@chromium.org> > wrote: > > > > I've been thinking about ways to make custom elements violate the > consistency principle less often and had a pretty awesome idea recently. > > > > Unfortunately I won't be at TPAC, but I'd like to discuss this idea in > person. Can we setup a custom element discussion later in the year? > > Certainly. I won't be back in the states until 11/8 and both Blink and > WebKit are having their contributor's meetings in the following week so how > about the week of November 16th? > > If not, the first and the second weeks of December also works. > > > The current "synchronous in the parser" model doesn’t feel good to me > because cloneNode() and upgrades are still async, > > I've been making a prototype of custom elements API in which cloneNode and > all other internal construction of elements are sync so only upgrading is > async in our design. > > > and I fear other things (ex. parser in editing, innerHTML) may need to > be as well. > > Not in our design. > > > So, while we've covered up the inconsistent state of the element in one > place (parser), we've left it to be a surprise in the others which seems > worse than just always being async. This led me to a crazy idea that would > get us consistency between all these cases: > > > > What if we use a different pimpl object (C++ implementation object) when > running the constructor, and then move the children/shadows and attributes > after the fact? This element can be reused (as implementation detail), and > any attempt to append it to another element would throw. > > This is not the first time this (or a similar) idea has been brought up. > > The problem with this approach is that authors can still find the old > non-temporary "pimpl" (where did this term come from?) via > querySelectorAll, getElementsByTagName, etc... because it's still in the > document. (If it's not in the document, then we would have the iframe > reloading problem) > I agree this is a problem. document.querySelector('some-creating-custom-element').parentNode being null is surprising. esprehn, could your proposal be spec'ed equivalently by saying that the APIs which look up the tree (parentNode, etc.) return null during "creation time"? > And when the constructors or unrelated code invoked by the constructor > access the old "pimpl", we have two options: > > 1. Use the same wrapper as the one we're creating. This is weird because > the element as perceived by other DOM APIs such as querySelectorAll and the > actual object behaves differently. > > 2. Create a new wrapper. But what are we going to do this with new wrapper > when we swap back "pimpl" after calling the constructor? Also, this would > mean that the identify of elements will change. > > There is yet another alternative: make all other DOM APIs behave as if > these pre-construction custom elements don't exist. However, that is a much > tricker thing to implement (especially if you didn't want to worsen the > performance) than making all construction sync at least in WebKit. > > - R. Niwa > > >
Received on Monday, 26 October 2015 02:35:54 UTC