Title: [Shadow]: Node should expose their scope so that shared state can be scoped to components. (bugzilla: 22080)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c0
Rafael Weinstein wrote on 2013-05-18 00:15:53 +0000.
It's not hard to imagine collection of elements working together and looking for each other within the same context.
ShadowRoot has getElementById and querySelectorAll on it, partially for this purpose.
Obviously, nodes can always walk up to the root element and inspect it to see if it's a document or ShadowRoot.
I propose that node should expose some time of treeScope property which is trivial checked. The C++ impl may walk up itself, and that's fine.
My main concern is components will be littered with implementations of findRoot(), or more likely, component authors scope shared state globally, either via window or document.
I.e. The main motivation would be encouraging proper encapsulation. If implementations can return the answer in constant time, that's just a bonus.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c1
Dimitri Glazkov wrote on 2013-05-20 16:32:57 +0000.
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)?
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c2
Rafael Weinstein wrote on 2013-05-20 17:11:40 +0000.
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.
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c3
Dominic Cooney wrote on 2013-05-21 02:20:04 +0000.
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? (???)
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c4
Rafael Weinstein wrote on 2013-05-23 23:16:56 +0000.
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.
comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c5
Hayato Ito wrote on 2014-05-29 06:30:26 +0000.
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?
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c6
Rafael Weinstein wrote on 2014-05-29 18:05:21 +0000.
I think it's fine to leave as a potential future feature when use cases are more clear
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c7
Hayato Ito wrote on 2014-12-12 06:08:22 +0000.
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.
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c8
Hayato Ito wrote on 2014-12-15 09:03:21 +0000.
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?
Title: [Shadow]: Node should expose their scope so that shared state can be scoped to components. (bugzilla: 22080)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c0
Rafael Weinstein wrote on 2013-05-18 00:15:53 +0000.
It's not hard to imagine collection of elements working together and looking for each other within the same context.
ShadowRoot has getElementById and querySelectorAll on it, partially for this purpose.
Obviously, nodes can always walk up to the root element and inspect it to see if it's a document or ShadowRoot.
I propose that node should expose some time of treeScope property which is trivial checked. The C++ impl may walk up itself, and that's fine.
My main concern is components will be littered with implementations of findRoot(), or more likely, component authors scope shared state globally, either via window or document.
I.e. The main motivation would be encouraging proper encapsulation. If implementations can return the answer in constant time, that's just a bonus.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c1
Dimitri Glazkov wrote on 2013-05-20 16:32:57 +0000.
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)?
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c2
Rafael Weinstein wrote on 2013-05-20 17:11:40 +0000.
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.
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c3
Dominic Cooney wrote on 2013-05-21 02:20:04 +0000.
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? (???)
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c4
Rafael Weinstein wrote on 2013-05-23 23:16:56 +0000.
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.
comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c5
Hayato Ito wrote on 2014-05-29 06:30:26 +0000.
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?
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c6
Rafael Weinstein wrote on 2014-05-29 18:05:21 +0000.
I think it's fine to leave as a potential future feature when use cases are more clear
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c7
Hayato Ito wrote on 2014-12-12 06:08:22 +0000.
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.
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22080#c8
Hayato Ito wrote on 2014-12-15 09:03:21 +0000.
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?