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
