W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Roland Steiner <rolandsteiner@google.com>
Date: Fri, 1 Jul 2011 10:59:04 +0900
Message-ID: <CACFPSpibCBT=+YobvWc06_rjSTvwjA2Ln+QdZwpUBzzMgcKkjw@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
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
Received on Friday, 1 July 2011 01:59:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT