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: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 30 Jun 2011 11:02:30 -0700
Cc: public-webapps <public-webapps@w3.org>
Message-id: <5D5A33DA-5363-4151-A9AF-E0D8F3E954C5@apple.com>
To: Dimitri Glazkov <dglazkov@chromium.org>

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
> (https://raw.github.com/dglazkov/component-model/cbb28714ada37ddbaf49b3b2b24569b5b5e4ccb9/dom.html)
> or even earlier versions
> (https://github.com/dglazkov/component-model/blob/ed6011596a0213fc1eb9f4a12544bb7ddd4f4894/api-idl.txt)
> 
> 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
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1345.html).
> 
> One of the things to keep in mind is that the proposal outlined in
> http://dglazkov.github.com/component-model/dom.html 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
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases.
> 
> 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?



Regards,
Maciej
Received on Thursday, 30 June 2011 18:02:59 GMT

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