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)

Other significant issues

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

• A call to registerElement() currently returned a generated constructor. This is surprising behavior, especially when a class has been supplied as an argument.

only run createdCallback when finished parsing? what about upgrades of children -- auto vs manual, tree order vs bottom-up attributeChangedCallback -- to avoid invoking every time a style property is changed would prefer microtask -- could use MO. or filter (list attributes you care about), in which case it could be any timing call attributeChangedCallback after created automatically? multiple registries -- haven’t had much discussion attached/detached callbacks insert-into-tree/removed-from-tree how to know whether a component is in the document (deep contains) design for ES6 modules