Apple's feedback for custom elements

Hi all,

Here's WebKit team's feedback for custom elements.


== Constructor vs createdCallback ==
We would like to use constructor instead of created callback.

https://github.com/w3c/webcomponents/issues/139

At the meeting, we should discuss what happens when a constructor throws during parsing and inside various DOM functions.

Supporting upgrades with constructor also poses a question as to whether we would be using [[Call]] or [[Construct]] on the constructor.  In the case we're using [[Construct]], associating the right call to `super()` will be difficult. In the following example, there will be three calls to HTMLElement's constructor:

```
class MyElement extends HTMLElement {
  constructor(notEvil) {
     var otherElement = notEvil ? null : new MyElement(true);
     var thisElement = super('my-element');
     var anotherElement  = notEvil ? null : new MyElement(true);
     var r = Math.random();
     return (r > 0.33) ? thisElement : (r > 0.66 ? otherElement : anotherElement);
  }
}
```


== 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.


== 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


== 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�ft meet author�fs expectation.


== 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.


== Attached/detached vs. inserted/removed hooks ==
Elements that define things or get used by other elements should probably do their work when they�fre 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


== 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


== 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.


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



== 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�ft think it poses a major combat issue.


== 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


== 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


- R. Niwa