[webcomponents]: <element> Wars: A New Hope

Inspired by Allen's and Scott's ideas in the "Benadryl" thread, I dug
into understanding what <element> actually represents.

It seems that the problem arises when we attempt to make <element>
_be_ the document.register invocation, since that draws the line of
when the declaration comes to existence (the registration line) and
imposes overly restrictive constraints on what we can do with it.

What if instead, the mental model of <element> was a statement of
intent? In other words, it says: "Hey browser-thing, when the time is
right, go ahead and register this custom element. kthxbai"

In this model, the proverbial registration line isn't drawn until
later (more on that in a moment), which means that both <element> and
<script> can contribute to defining the same custom element.

With that in mind, we take Scott's/Allen's excellent idea and twist it
up a bit. We invent a HTMLElementElement.define method (name TBD),
which takes two arguments: a custom element name, and an object. I
know folks will cringe, but I am thinking of an Object.create
properties object:

HTMLElementElement.define('x-foo', {
    erhmahgerd: { writable: false, value: "BOOKS!" }

When the registration line comes, the browser-thing matches <element>
instances and supplied property objects by custom element names, uses
them to create prototypes, and then calls document.register with
respective custom element name and prototype as arguments.

We now have a working declarative syntax that doesn't hack <script>,
is ES6-module-friendly, and still lets Scott build his tacos. Sounds
like a win to me. I wonder how Object.create properties object and
Class syntax could mesh better. I am sure ES6 Classes peeps will have
ideas here.

So... When is the registration line? Clearly, by the time the parser
finishes with the document, we're too late.

We have several choices. We could draw the line for an element when
its corresponding </element> is seen in document. This is not going to
work for deferred scripts, but maybe that is ok.

For <element>s that are imported, we have a nice delineation, since we
explicitly process each import in order, so no problems there.

What do you think?


Received on Wednesday, 17 April 2013 22:16:47 UTC