Re: Apple's feedback for custom elements

Random comments inline (other people from Mozilla may have different opinions)

On 01/24/2016 10:01 AM, Ryosuke Niwa wrote:
>
>
> Hi all,
>
> Here's WebKit team's feedback for custom elements.
>
>
> == Constructor vs createdCallback ==
> We would like to use constructor instead of created callback.
no comments

>
> == Symbol-named properties for lifecycle hooks ==
> After thorough consideration, we no longer think using symbols for callback names is a good idea.  The problem of name conflicts with an existing
> library seems theoretical at best, and library and framework authors shouldn't be using names such as "attributeChanged" for other purposes than as
> for the designated purpose of custom elements API.
>
> In addition, forcing authors write `[Element.attributeChanged]()` instead of `attributeChanged()` in this one API is inconsistent with the rest of Web
> API.
>
Personally I agree.

>
> == Calling attributeChanged for all attributes on creation ==
> We think invoking `attributeChanged` for each attribute during creation will help mitigating the difference between the upgrade case and a direct
> creation inside author script.
>
> https://github.com/w3c/webcomponents/issues/364
>
Fine to me. This is also close to what XTF had. (It had also a pre-callback, willSet/RemoveAttribute [1], but we can live without those at least in v1)


>
> == Lifecycle callback timing ==
> We're fine with end-of-nano-task timing due to the implementation difficulty of going fully sync and async model doesn’t meet author’s expectation.
>
nano-task scheduling sounds good.


>
> == Consistency problem ==
> This is a problem but we think calling constructor before attributes and children are added during parsing is a good enough mitigation strategy.
It is possible that we'll need beginAddingChildren()/doneAddingChildren() for the parsing case later, but not for v1.
I wonder if all the engines can easily have end-of-nanotask right after main-thread part of parser has created the DOM element and before any 
attributes/children are set.
IIRC Gecko should be fine these days.


> == Attached/detached vs. inserted/removed hooks ==
> Elements that define things or get used by other elements should probably do their work when they’re inserted into a document.  e.g. HTMLBaseElement
> needs to modify the base URL of a document when it gets inserted. To support this use case, we need callbacks when an element is inserted into a
> document/shadow-tree and removed from a document/shadow-tree.
>
> Once we have added such insertedIntoDocument/removedFromDocument callbacks, attached/detached seems rather arbitrary and unnecessary as the author can
> easily check the existence of the browsing context via `document.defaultView`.
>
> We would not like to add generic callbacks (inserted/removed) for every insertion and removal due to performance reasons.
>
> https://github.com/w3c/webcomponents/issues/362
I'd prefer getting more consistent parentChainChanged(oldSubtreeRoot, newSubtreeRoot) callback or some such. That wouldn't depend on is-in-document
state. Adding parentChainChanged later if there is already insertedIntoDocument/removedFromDocument would just duplicate some of the behavior.


Something to consider, borrowed from XTF, should custom element implementation tell to browser engine which notifications it is interested in?
That way performance considerations are partially moved from browser engine to the custom element author.


> == Style attribute spamming ==
> Since keeping the old value is inherently expensive, we think we should mitigate this issue by adding an attribute filtering.  We think having this
> callback is important because responding to attribute change was the primary motivation for keeping the end-of-a-nano-task timing for lifecycle callbacks.
>
> https://github.com/w3c/webcomponents/issues/350
attribute filter sounds good. Especially if it is consistent with MutationObserver.


> == childrenChanged callback ==
> Given the consistency problem, it might be good idea to add `childrenChanged` callback to encourage authors to respond to this event instead of
> relying on children being present if we decided to go with non-synchronous construction/upgrading model.
>
> On the other hand, many built-in elements that rely on children such as `textarea` tends to respond to all children at once.  So attaching mutation
> observer and doing the work lazily might be an acceptable workflow.
So would childrenChanged be called after parser has added all the child nodes? Or just at random time, or for each child nodes separately?

This is a case where beginAddingChildren()/doneAddingChildren() would be needed, but for now, childrenChanged is probably ok.


>
>
> == Upgrading order ==
> We should do top-down in both parsing and upgrading since parser needs to do it top-down.
no comments


>
>
>
> == What happens when a custom element is adopted to another document? ==
> Since a given custom element may not exist in a new document, retaining the prototype, etc... from the original document makes sense.  In addition,
> WebKit and Blink already exhibit this behavior so we don’t think it poses a major combat issue.
(can't recall all the details. Would need to re-read the relevant spec bugs.)


>
>
> == Inheritance from subclasses of HTMLElement such as HTMLInputElement ==
> We strongly oppose to adding this feature at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
Sounds good


>
>
> == Inheritance from SVGElement/MathMLElement ==
> We don't want to allow custom SVG and MathML elements at least in v1.
>
> https://github.com/w3c/webcomponents/issues/363
ditto


>
>
> - R. Niwa
>


-Olli

[1] http://mxr.mozilla.org/seamonkey/source/content/xtf/public/nsIXTFElement.idl#127

Received on Sunday, 24 January 2016 13:55:13 UTC