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

The key concept is that, to avoid timing issues, neither processing
<element> nor evaluating <script>[function-to-be-named-later]</script> are
the terminal point for defining an element.

Rather, at some third quantum of time a combination of those things is
constructed, keyed on 'element name'.

Most of the rest is syntax, subject to bikeshedding when and if the main
idea has taken root.


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

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