Re: Encapsulation and defaulting to open vs closed (was Re: Shadow DOM Encapsulation)

On Feb 6, 2014, at 4:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Feb 6, 2014 at 3:58 PM, Sylvain Galineau <galineau@adobe.com> wrote:
>> So I think the debate is not so much whether Type 2 can be added later as much as its being considered a future and therefore ‘nice-to-have’ feature instead of a ‘must-have’ default. Tab suggests you started from the latter point of view before reality pushed you to the former. Looking forward to hearing more on the how and why...
> 
> Reread the thread at
> <http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312>
> 

I did. This is good historical context and provides a bit more detail behind the reasoning though it’s still not so clear-cut or obvious to me. (though, as is the case now, it’s clear it’s obvious to you…)

I would note the thread seems to land in the same lack of consensus we have right now e.g.

Maciej http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html

	I still don't entirely buy the use cases for making shadow dom contents public. But I thought the 
	rough consensus in the earlier discussion was to support both modes, not to support public components only.

Earlier, BZ http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html:

	On 11/8/12 9:28 AM, Elliott Sprehn wrote:
	> If you're worried about malicious attacks on your widget, shadows being
	> private is not enough. You need a whole new scripting context.

	Er... yes, you do.  Do widgets not get that?  If not, that's pretty 
	broken…

Before that, BZ also http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0330.html:
 
	On 11/1/12 7:41 AM, Tab Atkins Jr. wrote:
	> There was no good *reason* to be private by default

	Yes, there was.  It makes it much simpler to author non-buggy 
	components.  Most component authors don't really contemplate how their 
	code will behave if someone violates the invariants they're depending on 
	in their shadow DOMs.  We've run into this again and again with XBL.

	So pretty much any component that has a shadow DOM people can mess with 
	but doesn't explicitly consider that it can happen is likely to be very 
	broken.  Depending on what exactly it does, the brokenness can be more 
	or less benign, ranging from "doesn't render right" to "leaks private 
	user data to the world".

	> As a general rule, we should favor being public over
	> being private unless there's a good privacy or security reason to be
	> private.

	As a general rule we should be making it as easy as possible to write 
	non-buggy code, while still allowing flexibility.  In my opinion.


It seems little progress has been made to close this gap :/

Received on Friday, 7 February 2014 00:36:32 UTC