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