> On Oct 24, 2015, at 9:55 AM, Elliott Sprehn <espr...@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) 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
