Re: Custom Elements: "createdCallback" & cloning

On 07/12/2015 08:09 PM, Anne van Kesteren wrote:
> On Fri, Jul 10, 2015 at 10:11 AM, Dominic Cooney <dominicc@google.com> wrote:
>> I think the most important question here, though, is not constructors or
>> prototype swizzling.
>
> I guess that depends on what you want to enable. If you want to
> recreate existing elements in terms of Custom Elements, you need
> private state.
>
>
>> - Progressive Enhancement. The author can write more things in markup and
>> present them while loading definitions asynchronously. Unlike progressive
>> enhancement by finding and replacing nodes in the tree, prototype swizzling
>> means that the author is free to detach a subtree, do a setTimeout, and
>> reattach it without worrying whether the definition was registered in the
>> interim.
>
> How does this not result in the same issues we see with FOUC? It seems
> rather problematic for the user to be able to interact with components
> that do not actually work, but I might be missing things.
>
>
>> - Fewer (no?) complications with parsing and cloning. Prototype swizzling
>> makes it possible to decouple constructing the tree, allocating the wrapper,
>> and running Custom Element initialization. For example, if you have a Custom
>> Element in Chromium that does not have a createdCallback, we don't actually
>> allocate its wrapper until it's touched (like any Element.) But it would not
>> be possible to distinguish whether a user-provided constructor is trivial
>> and needs "this."
>
> True true.
>
>
>> Could you share a list of things that use the cloning algorithm?
>
> In the DOM specification a heavy user is ranges. In turn, selection
> heavily depends upon ranges. Which brings us to editing operations
> such as cut & copy. None of those algorithms anticipate the DOM
> changing around under them. (Though perhaps as long as mutation events
> are still supported there are some corner cases there, though the
> level of support of those varies.)
>
> In Gecko printing also clones the tree and definitely does not expect
> that to have side effects.

Well, this printing case would just clone the final flattened tree without the original document knowing any cloning happened.
(scripts aren't suppose to run in Gecko's static clone documents, which print preview on linux and Windows and printing use)


If one needs a special DOM tree for printing, beforeprint event should be used to modify the DOM.


> Note that this would break with prototype
> swizzling too. Or at least you'd get a less pretty page when
> printing...
>
>
>> What do you mean by mode switch?
>
> That during cloning certain DOM operations cease to function, basically.
>
>

Received on Sunday, 12 July 2015 19:33:22 UTC