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

On Wed, Apr 17, 2013 at 6:16 PM, Dimitri Glazkov <dglazkov@google.com>wrote:

> 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:
>

The are called Property Descriptors.



>
> HTMLElementElement.define('x-foo', {
>     erhmahgerd: { writable: false, value: "BOOKS!" }
> });
>
>
This is just a repackaging of Object.defineProperties( target,
PropertyDescriptors ) thats slightly less obvious because the target
appears to be a string.


Rick





> 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?
>
> :DG<
>