Custom Elements: Upgrade et al

Open issues are kept track of here:

  https://wiki.whatwg.org/wiki/Custom_Elements

I think the most pragmatic way forward here is accepting that
constructing and upgrading need not be tied.

Synchronous constructors map most closely to what browsers do today
for builtin elements and open up the ability for an end tag callback
(which some elements need if you want to polyfill them, e.g. <module>)
and other hooks into the parser.

Synchronous constructors are problematic with cloning. My suggestion
is that cloning becomes a primitive similar to structured cloning and
that for v1 custom elements behave like <canvas>, not <input>. A clone
for an element also clones its associated shadow root (deep or not).

As to upgrades, we can consider some kind of notification mechanism
for elements created by the parser that gives the developer full
control over how to manipulate them. (Including when registering after
the fact.) Or perhaps libraries evolve around this and create some
kind of JavaScript module-based system for importing and using HTML
elements. In other words, I don't think we need to consider upgrades a
blocker for v1.

I propose we move upgrades to v2 and update the specification to use
synchronous constructors with a cloning primitive that does not
require invoking the constructor.

(By the way, I'm totally willing to help out with the specification
effort once I'm back from vacation in June. Finally get that DOM
integration underway, but that is conditional on cross-vendor buy-in.)


-- 
https://annevankesteren.nl/

Received on Wednesday, 6 May 2015 13:43:31 UTC