*"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 <al...@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 <dan...@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