On Dec 5, 2013, at 9:30 PM, Dimitri Glazkov <[email protected]> wrote: > On Thu, Dec 5, 2013 at 8:50 PM, Ryosuke Niwa <[email protected]> wrote: > On Dec 5, 2013, at 8:30 PM, Dimitri Glazkov <[email protected]> wrote: >> 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? > > For the following reasons to list a few: > We don't have any subclass of HTMLElement that can be instantiated and has > subclasses. > Not sure why this matters?
It means that inheritance is NOT integral part of the platform; at least for builtin elements. > Methods and properties of builtin elements are not designed to be overridden > by subclasses. > Okay, that seems like an implementation detail of HTML. Again, doesn't > preclude seeking consistency between inheritance from custom elements or HTML > elements. That's not an implementation detail. The key observation is that HTML elements aren't designed to be subclassed. > Behaviors of builtin elements will be changed by UAs in the future without > author-defined subclasses being "upgraded" accordingly, thereby violating > Liskov substitution principle. > Sure, it's probably a bad idea to inherit from any HTML element (other than > HTMElement). Great, then let's not support that. > The Custom Elements spec is deeply steeped in the idea that we bring new > functionality by explaining how the platform works (see > http://extensiblewebmanifesto.org/). If we just side-load some new platform > magic to accommodate a few specific use cases, we're not doing the right > thing. Without getting into a philosophical debate, supporting inheritance from subclasses of HTML elements doesn't explain how the Web platform works at all so let's not add that. If we removed this, we don't have to worry about attaching shadow DOM to builtin elements (other than HTMLElement itself) for custom elements. - R. Niwa
