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

On Jun 30, 2011, at 10:57 AM, Dimitri Glazkov wrote:

> Hi Maciej!
> First off, I really appreciate your willingness to get into the mix of
> things. It's a hard problem and I welcome any help we can get to solve
> it.
> I also very much liked your outline of encapsulation and I would like
> to start using the terminology you introduced.
> I am even flattered to see the proposal you outlined, because it's
> similar to the one we originally considered as part of the first
> iteration of the API
> (
> or even earlier versions
> (
> We did remove them however, and opted for the simplest possible API,
> which effectively only exposes the shadow DOM part of the component
> model (see my breakdown here
> One of the things to keep in mind is that the proposal outlined in
> is by no means a
> complete component model API. It's just the smallest subset that can
> already be useful in addressing some of the use cases listed in
> It seem obvious that it is better to have few small, closely related
> useful bits that could be combined into a bigger picture rather than
> one large monolithic feature that can't be teased apart.

The problem is that some pervasive properties (encapsulation, security, etc) can't be added after the fact to a system that doesn't have them designed in.

> As for addressing encapsulation concerns, one of the simplest things
> we could is to introduce a flag on the ShadowRoot (we can discuss the
> default value), which if set, prohibits access to it with the
> element.shadow property.

Why is that better than my proposal? I believe all the benefits I listed for my proposal over yours still apply to this new proposal. Can you either rebut those stated benefits, or tell me what benefits this version has over mine?


Received on Thursday, 30 June 2011 18:02:59 UTC