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)

Alternative is createdCallback return result from registerElement -- should be same class passed in, or else nothing finishedParsing callback -- missing 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