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

So let me be *crystal clear*:

If define() internally does this --> "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." - it's doing a hell-of-a-lot more than simply redirecting to
Object.create - in fact, I was thinking it would need to do this:

   - Retain all tagName-keyed property descriptors passed to it on a common
   look-up object
   - Interact with the portion of the system that handles assessment of the
   "registration line", and whether it has been crossed
   - and if called sometime after the "registration line" has been crossed,
   immediately invokes code that upgrades all in-DOM elements matching the
   tagName provided

I could be mistaken - but my interest is valid, because if true I would
need to polyfill the above detailed items, vs writing something as simple
and derpish as: HTMLElementElement.prototype.define = ...alias to
Object.create...

Dimitri, Scott can you let me know if that sounds right, for polyfill sake?

On Wed, Apr 17, 2013 at 4:11 PM, Rick Waldron <waldron.rick@gmail.com>wrote:

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