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
