Re: [webcomponents]: Of weird script elements and Benadryl

 >> have declarative custom element definitions but don't provide any
declarative mechanism for associating script with them

Seems to me this is the best approach.

In early discussions I had some objections, but I think these can be
overcome with a couple modifications.

The proposals to separate <element> from <script> have revolved around
associating a constructor name with <element>, then the constructor can be
instantiated anywhere. I had two objections to this: (1) requiring a global
symbol (or code to find the reference) and (2) that we cannot use
'standard' constructors for DOM nodes without being able to 'inherit
builtins', which is potentially a long way off.

To solve (1), I suggest we match code to <element> via the tag-name. We
already require this name and have to manage collisions, so there is no new
symbol.

document.register gets around (2) by (semi) future proofing the syntax. In
other words, where today we pass in a prototype and get back a constructor,
we left the door open for simply passing in a constructor in the future
(thus supporting ES6 classes). If make a second version of register used
for registering declarative components, we can use the same trick.

In other words,

<element name="x-foo" extends="button">
</element>
<script>
  ...
  HTMLElementElement.register('x-foo', dictionary);
</script>

'dictionary' can be {prototype: ...}, in which case we have (nigh)
equivalent functionality to the current spec/explainer/polyfill usage.

We can also support {constructor: ...} for registering pure classes when
ES6 lands (or if user wants to use an ES6 analog).

It may be possible to achieve this same thing using only document.register
(instead of creating a new method), it depends on some details.


On Tue, Apr 16, 2013 at 4:08 PM, Daniel Buchner <daniel@mozilla.com> wrote:

> *"Deferring just the script features of <element> would help with the
> timing and probably allow a better long term solution to be designed."*
>
> If the callbacks are not mutable or become inert after registration (as I
> believe was the case), how would a developer do this --> *"Imperative
> code could presumably make that association, if it needed to."*
>
>
> On Tue, Apr 16, 2013 at 3:47 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>wrote:
>
>>
>> On Apr 16, 2013, at 3:13 PM, Dimitri Glazkov wrote:
>>
>> > On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner <daniel@mozilla.com>
>> wrote:
>> >> One thing I've heard from many of our in-house developers, is that they
>> >> prefer the imperative syntax, with one caveat: we provide an easy way
>> to
>> >> allow components import/require/rely-upon other components. This could
>> >> obviously be done using ES6 Modules, but is there anything we can do to
>> >> address that use case for the web of today?
>> >
>> > Yes, one key ability we lose here is the declarative quality -- with
>> > the declarative syntax, you don't have to run script in order to
>> > comprehend what custom elements could be used by a document.
>>
>>
>> My sense is that the issues of concern (at least on this thread) with
>> declaratively defining custom elements all related to how custom behavior
>> (ie, script stuff) is declaratively associated. I'm not aware (but also not
>> very familiar) with similar issues relating to <template> and other
>> possible <element> subelement.  I also imagine that there is probably a set
>> of use cases that don't actually need any custom behavior.
>>
>> That suggests to me, that a possible middle ground, for now,  is to
>>  still have declarative custom element definitions but don't provide any
>> declarative mechanism for associating script with them.  Imperative code
>> could presumably make that association, if it needed to.
>>
>> I've been primarily concerned about approaches that would be future
>> hostile toward the use of applicable ES features that are emerging.  I
>> think we'll be see those features in browsers within the next 12 months.
>> Deferring just the script features of <element> would help with the timing
>> and probably allow a better long term solution to be designed.
>>
>> Allen
>
>
>