- From: Sylvain Galineau <galineau@adobe.com>
- Date: Fri, 7 Feb 2014 00:36:01 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: "dglazkov@google.com" <dglazkov@google.com>, "<www-style@w3.org>" <www-style@w3.org>
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