Re: [w3c/webcomponents] [Custom]: Callback for cloneNode/importNode (bugzilla: 24570) (#176)

This came up in TPAC 2016 Web Components/Mon discussion.

If I recall correctly Google and Mozilla expressed a preference for tree order, and there was no dissent. Microsoft and Apple were present but didn't state a preference. Here are [the minutes](https://www.w3.org/2016/09/19-webapps-minutes.html):

> bz: do we want to run them in tree order? before or after its kids?
>
> dcooney: callbacks run after everything is cloned
> ... the simplest way would be parents before children
>
> bz: might want to discuss with components authors
>
> Domenic: motivation is emulating builtins
> ... those don't depend on children
>
> koji: can those callbacks mutate the tree?
>
> Domenic: yes, but it's well-defined
> ... I'd like to add them in tree order
>
> annevk: like
>
> chaals: like
>
> dcooney: we could get some more feedback and decide Friday
> ... just to double check
>
> Domenic: SGTM
>
> weinig: I don't think we're against it, sounds fine
> ... there's a question of how often it's used
>
> bz: it would help to have actual use cases
>
> Domenic: if HTML modules takes off, you really need cloning
> ... so need to get some more feedback
> ... but generally sounds acceptable

I followed up with authors using web components at Google and they preferred tree order too. Their rationale was it is consistent with other callbacks in the platform.

@domenic Can you add this callback, passing the original element?

What should this callback do if the clone is being created in a document without a browsing context? The element being cloned may be a defined, custom element that has been moved into a document without a browsing context, because elements hang onto their definitions. But the document may not have a browsing context, so the clone would not normally be upgraded in that case. Maybe the callback should not fire in that case.

There's a similar question of what the callback does if the clone is being created in a document with a different window hence a different custom element registry. That registry may or may not have a matching definition. Maybe the callback should fire in that case? It would let an author who registers the same definition in every window in their app also pass state when cloning. The callback would have to check the defined pseudoselector, prototype, etc. to determine what to do with the clone. (In which case, cloning into documents without a browsing context could call the callback anyway for consistency.)

/cc @rniwa @bzbarsky 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/176#issuecomment-248842626