On Sat, Oct 24, 2015 at 4:02 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>
> > 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)
>
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
>
>
>
