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

On Wed, Apr 17, 2013 at 6:59 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> *"This is just a repackaging of Object.defineProperties( target,
> PropertyDescriptors ) thats slightly less obvious because the target
> appears to be a string."
> *
> Is another difference that the 'x-foo' doesn't have to be 'known' yet? It
> seems to be a bit more than a repack of Object.defineProperties to me.
>
>
I'm sorry if I was unclear, but my comments weren't subjective, nor was I
looking for feedback.

Looks like Dimitri agrees:
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0306.html

Rick



>
>
> On Wed, Apr 17, 2013 at 3:53 PM, Rick Waldron <waldron.rick@gmail.com>wrote:
>
>>
>>
>>
>> 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<
>>>
>>
>>
>