Re: [webcomponents] Auto-creating shadow DOM for custom elements

On Dec 9, 2013, at 11:13 AM, Scott Miles <sjmiles@google.com> wrote:
> I'm not wont to try to summarize it here, since he said it already better there. Perhaps the short version is: nobody knows what the 'standard use case' is yet.

How is that possible given we've already spent 2+ years on the whole web components effort?

> In previous adjudications, the straw that broke that camel's back was with respect to handling auto-generation with inheritance. Shadow-roots may need to be generated for each entry in the inheritance chain.

The problem with that approach is that it mixes inheritance with composition.

> Having the system perform this task takes it out of the control of the user's code, which otherwise has ability to modulate calls to super-class methods and manage this process.
> 
> class XFoo {
>   constructor_or_createdCallback: function() {
>     // my shadowRoot was auto-generated
>     this.doUsefulStuffLikeDatabinding(this.shadowRoot);
>   }
> }
> 
> class XBar extends XFoo {
>   constructor_or_createdCallback: function() {
>     super(); // uh-oh, super call operates on wrong shadowRoot
>   }
> }

This example doesn't work because the kind of encapsulation provided by shadow insertion point is not suitable for inheritance amongst UI components nor is available in other prominent GUI frameworks for the purpose of inheritance.

When subclassing a UI component, one has to either know what the superclass draws on the screen (so that you can modify them as needed or draw more stuff above or beneath it) or completely replace what's displayed.  Putting the superclass' content on some bounding box is a composition.  Let us not mix the two.

There are primarily two major use cases of inheritance in building UI "views":
Adding some non-GUI API for convenience - You don't need to touch the view at all.  Let the superclass draw/paint its view, and call its public API to modify the internal states as needed.
Provide a new UI but use the underlying data model - You don't need to use superclass' view.  Just draw/paint your own stuff.
Modifying what its superclass paints/draws to tweak the UI - You need to know exactly what superclass does.  Either superclass needs to provide a hook to do this or you need to know how superclass does its work so that you can intercept by overriding methods and callbacks as needed.

None of that involves putting superclass' view into some subregion in the subclass.  (We also argue that the first two use cases are better addressed by compositions on the Web for reasons I've stated elsewhere.)

- R. Niwa