On Apr 16, 2013, at 4:08 PM, Daniel Buchner 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."
Here is what I suggested earlier on this thread for what to do if a "constructor=" attribute wasn't supplied, when we were talking about that scheme: > 1) create a new anonymous constructor object that inherits from HTMLElement. > It wouldn't have any unique behavior but it would be uniquely associated > with the particular <element> that defined it and it might be useful for > doing instanceof tests. It would be the constructor that you register with > the tag. If that was done, it seems reasonable that the provided constructor object could be available as the value of an attribute of the HTMLElementElement that corresponds to the <element>. So, imperative code could lookup the HTMLElementElement based on its "name" property and retrieve the constructor object. The constructor object would have a "prototype" whose value is the actual prototype object used for these custom elements objects and the imperative code could assign methods. The script that assigns such methods would need to be placed to run after the <element> is parsed but before any other imperative code that actually makes use of those methods. Prototype objects are not normally immutable so there is no problem with delaying the installation of such methods even until after instances of the custom element have actually been created by the HTML parser. Allen > > 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 >
