W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Thu, 30 Jun 2011 15:01:38 -0700
Message-ID: <CADh5Ky0BCTHhO==gys3CNpUgUuV7oFD4cM0=vyaxe0O78paNHQ@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org
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.

> If you reuse the shadow DOM, you either don't get access to it from your
> component, or the old behavior still needs to be unhooked (since you can now
> violate its invariants).
> Does that match your mental model?  Or are we talking about totally
> different things somehow?

No, you've highlighted a real flaw in my reply there.

> -Boris
Received on Thursday, 30 June 2011 22:02:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC