Custom Elements: Contentious Bits

This document is meant to summarize the more pressing issues related to the Custom Elements spec. These issues are either blocking adoption of the spec, or else significant concerns raised by experimentation with the current Google proposal.

This page is meant to document the issues and most likely options for resolving those issues, and not to argue for a specific resolution of any issue. If you see a significant issue which is not yet represented here, or your own position on the issue isn't reflected yet, or there's a pro/con on a position which should be considered, please add it.

constructor behavior

Position A: Ignore custom element constructor

This is the current behavior in the spec. Components are expected to perform initialization in a subsequent asynchronous createdCallback or attachedCallback.

Pros:

• (pros go here)

Cons:

• (cons go here)

Position B: Allow a constructor to perform component initialization

The component can perform initialization of variables in a standard ES6 constructor function. and require that it (somehow) invoke the base HTMLElement constructor

Pros:

• (pros go here)

Cons:

• (cons go here)

Detecting addition/removal from the document

Position A: Use attached/detached callbacks that apply to the document

Position B: Use inserted/removed callbacks that apply to any tree

Other significant issues

These haven't yet been analyzed enough to develop clear positions on them.

• It's unclear what's the earliest point at which a component can expect all of its children to be present. The createdCallback can hypothetically fire before all children are present. This means the component may prematurely perform work on a subset of the final children, or may need to redo work later when all children are finally present.

• Related to the above point, if a component contains children which are also components, when can the containing component expect to know those children have been upgraded? Is upgrade done in tree-order or bottom-up?

• A call to registerElement() currently returned a generated constructor that will differ from the class which was passed in. This is surprising behavior.

• Should attributeChangedCallback be invoked every time a style property is changed? Should this callback be dropped, and the component rely on observing mutations on itself to become aware of attribute changes? Should attributeChangedCallback take a filter of attributes the component is interested in tracking?

• Related to the above point, should attributeChangeCallback be fired automatically for a new component? An emerging pattern is that a createdCallback or attachedCallback often loops over all its attributes so that it can marshall those to properties. It would be easier if this were handled automatically.

• How can we resolve name conflicts in element tags? Should we support multiple registries? In designing for ES6, is the expected pattern for a component module to just export a class that can registered by the importer, or is the module expected to register the component itself (that is, as a side effect)?

• How does a component know when it is in the document: i.e., how can it do a deep contains()?