Re: Custom Elements: "createdCallback" & cloning

On Mon, Jul 13, 2015 at 4:32 AM, Olli Pettay <olli@pettay.fi> wrote:

> 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.
>>
>
Yes. I am trying to interpret this in the context of the esdiscuss thread
you linked. I'm not sure I understand the problem with private state,
actually. Private state is allocated for DOM wrappers in Chromium today
(like Gecko), including Custom Elements; it's not a problem. DOM wrapper
creation is controlled by the UA, which can arrange for allocating the
slots.

Is there a plan for author classes to be able to have private state or
something?


>>  - 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.
>>
>
Although you mention FOUC, this isn't the same as FOUC because the
component can be styled (particularly with :unresolved). But as you go on
to mention, there is the question of interactivity. Here are my
observations:

- In some cases, the user may not care that the component is briefly not
interactive. For example, have you noticed that the GitHub "3 days ago"
labels don't have their definitions briefly?

- In some cases, the author can continue to use things like onclick
attributes to provide some fallback interactivity.

- In the majority of cases, you have to ask what's better. Is it better to
have some presentation (like an :unresolved rule showing a loading spinner,
maybe with animated transitions to the interactive state) with the page
scrollable and other things interactive, or a blank page blocked on
definitions?

 - 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.)
>>
>
Thanks. I can understand how editing and Range.cloneContents would use
cloning. How is it relevant that Range is depended on by Selection?
Selection may delete things but it does not clone them.


> 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.
>>
>
This sounds interesting; it may even be useful for authors to be able to
assert that between two points they did not modify the DOM.