Re: Component Models and Encapsulation (was Re: Component Model: Landing Experimental Shadow DOM API in WebKit)

On Fri, Jul 1, 2011 at 7:01 AM, Dimitri Glazkov <dglazkov@google.com> wrote:

> On Thu, Jun 30, 2011 at 2:50 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 6/30/11 5:45 PM, Dimitri Glazkov wrote:
> >>
> >> There's a very interesting distinction here. You don't "attach"
> >> components to DOM elements. DOM elements _are_ components. The only
> >> way to make a component is by sub-classing it from an existing
> >> element. In this case, there is no distinction between native and
> >> non-native implementations. If I sub-class from HTMLTextareaElement, I
> >> can either reuse or override its shadow DOM.
> >
> > Back up.
> >
> > In this particular case, there may well be behavior attached to the
> textarea
> > that makes assumptions about the shadow DOM's structure.  This seems like
> a
> > general statement about components.
> >
> > So if you override a shadow DOM, you better override the behavior too,
> > right?
>
> Ouch. This one is tricky. I now see it. We can't really expect the
> author to design to this level of decoupling.


I don't think that's insurmountable. Since we don't do "aspect oriented
components", a component's tree is always the same - either at the root, or
attached to some <inherited> element of a sub-class component. So the
behavior can work on that tree without having to know whether it's used
vanilla, or within a sub-class.

Now, if the sub-class doesn't in fact use <inherited>, that means its
component tree in effect overrides the original component's tree. The
original tree and it's attached behavior are just ignored and go hide in a
corner.

However, (later on) we may need then to also allow sub-classing the
behavior, i.e., handing off of the interface of the original component to
its sub-class. That in turn may have security implications - you probably
don't want a component to be able to sub-class a file-upload control and
hijack events, etc.


Cheers,

- Roland