I am a bit hesitant to expose this whole guts of plumbing, given that TreeScope is uninteresting in itself. I wonder if we could get away with just letting any element find out which ShadowRoot it belongs to in O(1)?

What's the difference?

The general point is that a node may wake up and want to know what *tree* it is in. In general elements should be tolerant of being in the main document or being in the shadow of another element.

The basic goal here is to formalize the way that elements can figure out "who is my root thingy" without boilerplate of findRoot() littered all over.

The good thing about adding something that returns the ShadowRoot is that it is easy to write:

if (in document) {
  behave
} else if (in shadow) {
  misbehave
} ...

But it makes it harder to write "do something to my root node"; instead of

elem.treeScope.party();

it is

(elem.containingShadow || elem.document).party();

I think having the shadow root accessor is better because it is very easy to explain. Otherwise we'll have to put this pop quiz on cereal packets:

What does elem.treeScope return when...
...elem is not in the tree? (null)
...elem is in light DOM? (document)
...elem is in template content? (template document, I guess?)
...elem is in shadow DOM? (Shadow Root)
...elem is in a document fragment? (???)

I can't tell if we're talking at cross purposes or not. I'm probably just being dense.

The point I'm trying to make is that, for the sake of encapsulation, I think it makes the most sense to think about being directly descended from a ShadowRoot like being in a "little" document.

The key question that the node needs to answer is: "which document-like thing am I inside, if any". If I'm not inside any, there's nothing to do, if I'm inside one, I may go looking for local (encapsulated) shared or configuration data *at* that document-like thing (the root of my encapsulated context).

This seems only natural to me. Maybe I'm suggesting that we need a need Interface which implemented getElementById and both Document and ShadowRoot implement that interface. node.treeScope would then return that interface if the node had one.

To answer the questions above:

What does elem.treeScope return when...
...elem is not in the tree? (null)
...elem is in light DOM? (document)
...elem is in template content? (null)
...elem is in shadow DOM? (Shadow Root)
...elem is in a document fragment? (null)

The point is that ShadowRoots essentially become *local* documents. I claim this is inline with the web components mantra of enabling local thinking.

This issue looks a little outdated.

I'm not sure whether this API, such as node.treeScope, is worth adding or not.

Does someone have still a strong interest on this?

I think it's fine to leave as a potential future feature when use cases are more clear

Let me keep this open.

For me, comment #4 sounds reasonable. I don't have any reason to object to this feature request. I am wondering why this feature request has not had another +1 from others?

I guess other guys hasn't discovered this feature request, or they all are satisfied with their *polyfill. Hmm.

If someone want to this strongly, please let us know that.

Looks like that developers are making a polyfill for this issue:

http://stackoverflow.com/questions/27453617/how-can-i-tell-if-an-element-is-in-a-shadow-dom

I don't think this is a good situation because a polyfill might take O(N) while the platform can answer that in O(1).

I am positive to add a node.scope or something else. Could we agree on this?

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