On Thu, Dec 5, 2013 at 7:55 PM, Ryosuke Niwa <[email protected]> wrote:
> On Nov 11, 2013, at 4:12 PM, Dimitri Glazkov <[email protected]> > wrote: > > 3) The approach pollutes global name space with constructors. This had > been voiced many times as unacceptable by developers. > > > > 4) How does build a custom element that uses <name-card> as its base > element? What about <div> or any other HTML element? > > > > The last one remains to be the hardest. The tortured inheritance support > is what killed <element> in the first place. We can't ignore the > inheritance, since it is clearly present, in both DOM and JS. If we attempt > to punt on supporting it, our decisions cut off the opportunities to evolve > this right in the future, and will likely leave us with boogers like > multiple syntaxes for inheritance vs. non-inheritance use cases. > > What exactly are you referring to by inheritance support? > Inheritance from all builtin elements (e.g. subclasses of HTMLElement)? > > Or inheritance from custom elements authors have defined? > Sure, both are fine. Why should we treat them differently? > > And could you give us a pointer for a list of concrete use cases? Look at any mature Web framework. They all have hierarchies of objects: http://docs.sencha.com/extjs/4.2.2/#!/api http://quickui.org/catalog/ The latter is undergoing a complete rewrite to be custom element-based, so you might find it useful to study: https://github.com/JanMiksovsky/quetzal If the atomic unit of your framework is a DOM element, then DOM elements must support being extended via inheritance. Jan Miksovsky (cc'd) is a good person to talk about inheritance properties of custom elements. :DG<
