- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 6 Feb 2014 17:36:11 -0800
- To: Sylvain Galineau <galineau@adobe.com>
- Cc: "dglazkov@google.com" <dglazkov@google.com>, "<www-style@w3.org>" <www-style@w3.org>
On Thu, Feb 6, 2014 at 4:36 PM, Sylvain Galineau <galineau@adobe.com> wrote: > 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… I can't comment as to whether Boris was just confused on that point a year ago, or what, nor what his thoughts are on it now. It's definitely been clear for a long time in Shadow DOM-land that we're not trying to solve the script-encapsulation problem (aka the "explain <iframe>s" problem). > 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 :/ Same deal here. Boris makes a good point that we should give thought to allowing authors to write their code with high-fidelity security primitives, but nothing we've discussed so far would do that. Most certainly, trying to restrict CSS's ability to style into a shadow DOM won't affect this at all. However, this entire topic is straying WAY beyond what's appropriate for this forum. The CSSWG is *not* the right body to second-guess decisions made a year ago in WebApps about core Shadow DOM functionality, and I'm going to stop responding to any attempts to talk about this stuff in www-style. For the purpose of the www-style threads, we should take the current spec as given. If you disagree, do so in a WebApps thread or bug. ~TJ
Received on Friday, 7 February 2014 01:36:59 UTC