It seems that having a distinction of a "private" shadow tree is a misnomer, possibly giving the author a false hope that their shadow tree is somehow protected from a motivated owner of the document. Unfortunately, that's not the case -- the document can easily override and capture all shadow trees created, thus killing the shadow author's illusion of privacy.

This public-webapps thread is informative: <http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0800.html>

So, any progress on this?

(I'm not sure if you are using Bugzilla's Importance field; if so, I bumped this up to P1 given recent discussions.)

(In reply to Edward O'Connor from comment #3)
> So, any progress on this?

Not yet. But it's still on the radar.

BTW, this should also disable access via relevant CSS selectors (http://dev.w3.org/csswg/shadow-styling/).

Suggestion: how about instead of private vs public, the flag is "open" vs "closed"? That won't unduly promise security isolation. Then a hypothetical third truly secure mode could be called "secure" or "sandboxed" and it would be consistent.

This public-webapps thread is informative: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/thread.html#msg217

It seems to me that there are different concerns you might talk about, not entirely unlike sandboxed iframes.  Shadow DOM (as currently) provides a nice simple membrane to keep lots of accidental things from going wrong, but can be easily traversed into/pierced and doesn't get a separate execution context or anything special.  If we had a ::parts concept it would be useful to explain what that means in terms of CSS and DOM boundaries, etc.

Is it possible to consider, instead of a flag, that a shadow root has a set of properties (which I hope default to what they currently are in canary, personally).  This would probably help explain things in the platform even if we never entirely enable them in author space, if you see what I am saying.

*** Bug 16509 has been marked as a duplicate of this bug. ***

Let me change the subject of this bug since I am feeling that we tend to use 'closed' rather than 'private'.

*** Bug 23134 has been marked as a duplicate of this bug. ***

(In reply to Hayato Ito from comment #10)
> *** Bug 23134 has been marked as a duplicate of this bug. ***

Please consider my concerns raised in this comment https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775#c11

It looks like 'closed' mode has been added to the spec, but not yet a way to enter it (this bug) or a spec of its behavior (bug 27775).

The status of the behavior of the closed mode is still WIP. There are still remaining tasks. I have to address how event.path() should work for closed shadow trees further at least.

What's the more important is that we don't have a clear idea how open / closed interact in multiple shadow trees. I'm still investigating.

Does adding a parameter to createShadowRoot() require solving all those problems first?

(In reply to Maciej Stachowiak from comment #14)
> Does adding a parameter to createShadowRoot() require solving all those
> problems first?

Good question. No. This bug shouldn't depends on bug 27775 strictly in terms of the spec. We can do in parallel!

Let's move this bug forward.

I think the proposal so far is to make createShadowRoot() can take one optional dictionary, such as:

- createShadowRoot({'mode': [closed/open]})

Is there any other proposal?

Unless there is any other proposal, let's me spec that tentatively.

Done tentatively at https://github.com/w3c/webcomponents/commit/7be4645926583dba2a3b137609885b3c4ee4205f.

I appreciate any feedbacks.

Looks like a good starting point for the API. Thanks! I think the remaining issues are captured in bug 27775 (to define the behavior) and bug 28445 (to determine the default) so I think it would be reasonable to close this bug now.

Let me reopen this.
Now ShadowRootInit should be mandatory.

There is also the issue of naming. At the F2F many people were saying that "closed" vs. "open" is not a good name for this because the existing mode is fairly closed already.

I offer { censored: true }/{censored: false } since its primary function is to censor shadowRoot, deepPath, and any other future properties.

How about visible/hidden/isolated?

censored doesn't really say much, IMO.

visible, hidden, isolated - I think I like that.

(better than public/protected/private)

"visible" still doesn't seem correct. Unless you are using visible to refer to the light DOM, and hidden is { closed: true }?

"visible" when passed to createShadowRoot() quite naturally hints that the
created shadow root is visible to the outside users, no?

No, to me it hints that the resulting DOM is visible like normal DOM is, not that it's hidden from CSS selectors and from access without the .shadowRoot indirection.

I think if we want a spectrum of terms we need to have it include light DOM at one end. E.g.

- Light DOM: visible
- Shadow DOM: shadow
- Shadow DOM, censored access: hidden
- Shadow DOM, isolated global: isolated

Sorry, to clarify: I just want some straightforward terminology. We of course wouldn't allow .createShadowRoot({ mode: 'visible' }) in my scheme. I just want to talk about what mode a subtree is in and have a word for what mode it's in when there's no shadowey stuff going on.

Moved to https://github.com/w3c/webcomponents/issues/100

Don't make it impossible for scripts to access nodes in or distributed in a shadow tree. Why? What if we want to have privileged chrome code modify or read content from a page, to alter or enhance a page's behaviour? What if we want to programmatically interact with nodes within a shadow boundary? If scripts have no access to these... this is impossible. It is essentially a form of DRM for any content on the web. The workaround is to recompile Chrome from source and revert changes that introduce these restrictions, in effect forking the browser.