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

It probably goes without saying, but, as far as I know this is the best
idea on the table so far.

Couple notes:

> erhmahgerd: { writable: false, value: "BOOKS!" }

I don't know why we would use 'propery definitions' there. If you let me
pass in an object, I can define the properties however I like.

> When is the registration line

It's hard for me to see any way other than after all 'imports' and
'scripts' have been processed. At that point you would need to do an
upgrade step, and fire some kind of 'all done' event after that.

S


On Wed, Apr 17, 2013 at 3: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:
>
> 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?
>
> :DG<
>