'in a Document' for shadow trees #57
Comments
|
So what is happening with this. We need all the is-in-document cases resolved before we can have |
|
WebKit considers a node is in the document if its ancestors or its shadow host is in the document (whose in-document-ness is recursively defined as such). |
|
Ok, so not following the current specs but doing something else. |
|
label.htmlFor as an example is a case where we don't want shadow DOM to be treated as if it was in document |
|
I think we need to update the HTML spec to respect the shadow boundary in those cases. |
|
Exactly, and we need to do that before we can have interoperable implementations. Without that we'll end up having each implementation guessing what should happen in each cases. |
|
Ops. This migrated issue looks difficult to read. Please see the original discussion In summary, this section in the spec reflects what we had agreed: Please add any feedback to this section before upstreaming it to the HTML standard. After Shadow DOM spec becomes stable, we should upstream this section to the HTML Standard somehow. AFAIR, we didn't have a plan to change the definition of "in a document". |
|
I don't think it makes sense to change the definition of the concept "in a document" based on the element type (as done in the current working draft). We should instead change each concept that refers to "in a document" concept. Also, the current WD refers to the concept of inertness but this concept exists only for nodes hidden by a In addition, "in a document" state should NOT depend on the concept of being rendered as that depends on CSS box models, etc... whereas the concept of being "in a document" should be a purely DOM concern. Furthermore, a node "particitpat[ing] in a composed tree whose root node is a document" is very different from "being rendered". |
|
@rniwa Regarding with "being rendered", I remember that I needed a good convenient terminology and used that in the spec. It looks that we have to use "being rendered" and "particitpat[ing] in a composed tree whose root node is a document" for different purposes. Regarding with inertness, I agree that it's not good idea to re-use "inertness" in the Shadow DOM spec. |
|
We need to get some hooks to HTML spec which Shadow DOM spec then refers to or vice versa, or And indeed, something being rendered or not shouldn't affect to any of this. |
|
Feels like we need some more resources here to go through all the specs and figure out what should happen in each case. This is really case-by-case work. And getting HTML spec fixed in higher level Anyone have some spare time? CCing also |
|
@smaug---- https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c53 and onwards contains the relevant elements and questions related to them. E.g., what should |
|
Let me remove I would like to reduce the number of issues with v1 label so that we can focus on resolving contentious bits. |
|
I'm not sure if I get the discussion correctly. Do you have any agreement on how for example Should, it be executed as it is in document tree (=> "in Document")? Sorry for flooding your topic with my issue reference, I was just quoting the spec. |
|
A script element child of a host element will definitely run, distributed or not. Once #382 is resolved I'll make sure the HTML Standard is updated. I suppose I could start filing issues there for the various affected features. |
hayatoito
changed the title
Title: [Shadow]: Need an equivalent definition of 'in a Document' for shadow trees (bugzilla: 26365)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c0
Hayato Ito wrote on 2014-07-17 04:13:53 +0000.
The context is:
https://code.google.com/p/chromium/issues/detail?id=393350
https://code.google.com/p/chromium/issues/detail?id=394327
According to the current definition of a 'in a Document' 1, some important features, such as scripting, should not work in shadow trees as per the spec.
Because I am afraid that it's not a good idea to change the definition of 'in a Document', we need a better terminology for alternative of 'in a Document', such as 'in a Document or in a shadow tree', and should fix the relevant specs by using that.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c1
Boris Zbarsky wrote on 2014-07-17 05:25:53 +0000.
That's wrong if the shadow host in the light DOM is not in a document.
What are the cases in which you'd want different behavior between "in a Document" and whatever your new concept is?
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c2
Hayato Ito wrote on 2014-07-17 05:56:31 +0000.
(In reply to Boris Zbarsky from comment #1)
I think that should be 'in a composed tree whose root element is a Document'.
That's still a tentative idea, though.
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c3
Boris Zbarsky wrote on 2014-07-17 06:01:05 +0000.
Yes, but what will break if the definition of "in a Document" is changed to mean that (with s/element/node/, I assume).
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c4
Hayato Ito wrote on 2014-07-17 06:10:44 +0000.
(In reply to Boris Zbarsky from comment #3)
Ops. An aggressive idea! I can't predict the impact of this change, however, I like it. :) That should be no impact, I hope.
I just thought that there are some cases where we want to distinguish 'in a Document' and 'in a composed tree whose root is a Document'.
comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c5
Olli Pettay wrote on 2014-07-17 09:41:05 +0000.
I would start with shadow DOM being not-in-document by default and then case by
case verify that if the host is in doc how various features should work.
Otherwise we may easily accidentally leak internals of shadow dom to the
outside worlds, like in case of https://code.google.com/p/chromium/issues/detail?id=394332
comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c6
Boris Zbarsky wrote on 2014-07-17 12:35:11 +0000.
This isn't something to hope; this is something to audit in the specs; comes with changing the fundamental conceptual model...
That said, one of the very first hits on "in a Document" in HTML is in "reset the form owner", and in that case it's not clear to me that things inside a shadow DOM should be considered "in a document".
So it does sound like shadow DOM should not be "in a document" by default but we need a new term X for "light DOM nodes are X if in a document, shadow DOM nodes are X if shadow host is X" that other specs then need to be adjusted to use. That means filing spec bugs on those specs.
Normally this would happen either during specification or implementation; it's a bit disturbing to me that neither one happened here so far until we started implementing, since it suggests Chrome wasn't actually implementing what the spec says. :(
comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c7
Hayato Ito wrote on 2014-07-18 03:38:29 +0000.
Yet another related issue:
https://code.google.com/p/chromium/issues/detail?id=394295
comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c8
Hayato Ito wrote on 2014-07-18 03:53:31 +0000.
One more:
https://code.google.com/p/chromium/issues/detail?id=394307
Once we can resolve the spec bug, blink guys should triage these relevant bugs.
comment: 9
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c9
Hayato Ito wrote on 2014-07-18 04:40:32 +0000.
(In reply to Boris Zbarsky from comment #6)
Agreed on that we should proceed in a careful way. We must audit the usage of 'in a Document' in specs, right?
That might not be an easy task. However, I am sure we can agree that we should be careful here.
I think we have to distinguish the following cases:
(That means there is a state where node is in 1, but not in 2, such as a node which is a child of a shadow host, but it's not distributed.)
We might want to have a new TERM x to represents the state of 2 (and 3?).
comment: 10
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c10
Hayato Ito wrote on 2014-07-18 07:18:49 +0000.
I think the previous classification is not good. The following might be better:
(1): A node is in a Document. The meaning of this doesn't change.
(2): A node is in a shadow tree which participates in a tree of trees whose root tree is a document tree.
(3): (1) or (2). We might want to call it, "A node is in a tree of trees rooted by a Document".
(4). A node is in a composed tree whose root is a Document.
Note that a node can be ((3), but not in (4)) when a node is a child of a shadow host, but the node isn't distributed to anywhere.
comment: 11
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c11
Olli Pettay wrote on 2014-09-19 11:49:10 +0000.
I don't understand the difference between 3 and 4.
"A node is in a tree of trees rooted by a Document" vs
"A node is in a composed tree whose root is a Document"
comment: 12
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c12
Ian 'Hixie' Hickson wrote on 2014-09-20 01:19:07 +0000.
First step here seems to me to be to enumerate all the cases we care about.
comment: 13
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c13
Hayato Ito wrote on 2014-09-22 01:27:00 +0000.
(In reply to Olli Pettay from comment #11)
For example, the following codes could be in (3), but not in (4):
These nodes couldn't participate in the composed tree.
comment: 14
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c14
Hayato Ito wrote on 2014-09-22 01:27:58 +0000.
s/codes/nodes/
comment: 15
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c15
Hayato Ito wrote on 2014-09-22 01:34:54 +0000.
(In reply to Ian 'Hixie' Hickson from comment #12)
Yeah, I agree.
We have to enumerate all cases where "in a Document" is being used in relevant specs and have to make a decision whether we can leave the usage of "in a Document" as is or replace the usage with better terminology, which we haven't had yet. :(
comment: 16
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c16
Olli Pettay wrote on 2014-09-22 09:41:16 +0000.
(In reply to Hayato Ito from comment #13)
I see. In Gecko we're going to make, at least for now until the spec
is clarified, nodes in a shadow host, but not distributed, to behave
like it was in a disconnected subtree.
comment: 17
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c17
Ian 'Hixie' Hickson wrote on 2014-09-26 18:29:23 +0000.
So who is going to go through and file the bugs for the relevant cases? I don't know Web Components well enough to do this myself.
comment: 18
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c18
Ian 'Hixie' Hickson wrote on 2014-09-26 18:36:11 +0000.
Seems like this should include cases like how radio buttons pick their radio button group, how scripts decide if they should execute (and if they do, whether document.currentScript is the right API to update when they execute), how labels decide what controls they are labelling, how getElementById() and getElementsByTagName() work, whether iframes should load in shadow trees, what gets included in APIs like document.links, how image maps are found, how target=""s are found, etc.
This seems pretty critical.
comment: 19
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c19
Hayato Ito wrote on 2014-09-29 06:38:51 +0000.
(In reply to Ian 'Hixie' Hickson from comment #17)
I thought I had to do. I guess I'd need help from experienced spec editors.
This issue has been in my TODO list, however, I couldn't spend my time on this at all so far.
I am aware that this is an important issue, however, to be honest, it's likely that I can't start this task in a few weeks.
comment: 20
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c20
Hayato Ito wrote on 2014-09-30 07:12:10 +0000.
Yeah, this is super critical. How should we proceed? I appreciate advice from experienced spec editors.
Here is very rough current plan how to proceed:
Define good terminologies, as I described in comment 10, so that we can use these terms to update specs.
This might be important because well defined terminologies would make it easy to update the spec.
To define a good terminology set, we might want to pick up some concrete examples from currently filed bugs so that the terminology set is really helpful.
Go though specs and file bugs.
e.g. One master (meta) bug and other relevant bugs which depends on the meta-bug.
Use our best judgement and update the spec in each filed bug.
(In reply to Ian 'Hixie' Hickson from comment #18)
comment: 21
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c21
Hayato Ito wrote on 2014-10-01 11:37:57 +0000.
Let me share my very rough memo as a basis for discussion.
Let's use the following trees as an example:
Closing tags are being omitted.
HTML:
The node #A hosts three shadow trees as follows, from older to younger:
oldest-shadow-root
older-shadow-root
youngest-shadow-root
In addition, suppose that we have disconnected nodes as follows:
var o = document.createElement('div');
var p = o.createShadowRoot();
The composed tree will be:
document:
We can classify the nodes as follows:
A). In a document x x x x x
B). In a shadow tree x x x x x x x x x X
C). In a composed tree (root is a document) x x x x x
D). In a tree of trees (root is a document) x x x x x x x x x x x x x x
E). Disconnected (from D) x x
comment: 22
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c22
William Chen wrote on 2014-10-02 01:25:14 +0000.
It may also be useful to define a new type of parent/child relation for nodes in composed trees and tree of trees. The terms "parent", "child", "ancestor" and "descendant" may not make sense if we change things from "in document" to "in composed tree rooted at document" or "in tree of trees rooted at document".
Just as an example, one of the steps in the "reset the form owner" algorithm 1 involves finding "the nearest such ancestor form element". If we wanted to allow form-associated-element to associate with forms outside the shadow tree, then the current algorithm isn't sufficient because the parent chain terminates at the shadow root and "nearest ancestor" may not be the node you want.
For "in document" and "in shadow tree", using the current terminology is probably fine.
For "in composed tree" we probably need new terms that describe a parent/child relation between shadow host/shadow root and parent of insertion points/nodes distributed into insertion points. Nodes that are distributed but don't match an insertion point should probably have no parent in this relation.
For "in tree of trees" we would probably also need terms to describe parent/child relation between shadow host/shadow root, but ignore insertion points and distribution.
1 https://html.spec.whatwg.org/multipage/forms.html#reset-the-form-owner
comment: 23
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c23
Hayato Ito wrote on 2014-10-02 10:49:28 +0000.
Good point. Unless otherwise noted, I think parent/child relations for nodes should mean the relation in a document tree or a shadow tree. The meaning shouldn't change.
In regard to 'parent/child relation in composed trees', I've being using 'a parent node in a composed tree', for example, unofficially, in code reviews in chrome. We might want to have a better term.
In regard to 'parent/child relation in a tree of trees', the situation is not so simple. Although I used a term of 'In a tree of trees (root is a document)' in the previous comment, this is a kind of abbreviation for 'In a node tree which participates in a tree of trees whose root tree is a document tree'.
The participant of 'tree of trees' is not a node. That's a node tree.
You might want to know that the spec already have terms, 'child or hosted shadow root' 1 and 'deep descendant' 2.
I've introduced that when I tried to introduce 'deepContains' [3].
I am aware that this definition doesn't define the tree order between sibling nodes in a tree of trees yet.
[3]: That's reverted in 463916e
comment: 24
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c24
Hayato Ito wrote on 2014-10-28 02:08:58 +0000.
Yet another relevant issue in chromium bug tracker: https://code.google.com/p/chromium/issues/detail?id=426050
comment: 25
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c25
Boris Zbarsky wrote on 2014-10-28 02:36:23 +0000.
That's covered by bug 26943, which is blocked on this bug... that was clearly stated in the chromium bug you reference.
comment: 26
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c26
Hayato Ito wrote on 2014-10-31 04:55:43 +0000.
It seems there are a lot of things to todo, however, I think
defining D (with a good naming) clearly in the spec and replace 'In a document' with D where we need to update is a low-hanging fruit and good starting point for us.
comment: 27
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c27
Olli Pettay wrote on 2014-10-31 11:00:36 +0000.
Do f and g actually belong to D. I'd expect f and g to behave as if they were
in a disconnected subtree which has ShadowRoot as the root.
f and g after all don't affect to layout nor participate event propagation path.
comment: 28
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c28
Hayato Ito wrote on 2014-11-06 22:06:18 +0000.
I am okay that we should exclude f and g from D.
That made me think about yet another case. Suppose that node #c (or #d) has a shadow tree, do we consider the shadow tree hosted by #c (or #d) disconnected?
That means the shadow host, #c, itself is not disconnected, but the nodes in the shadow tree hosted by the shadow host, #c, are disconnected. Is it weird?
If you notice any other missing case, please let me know that.
BTW, if someone has a good naming candidate for D, it's highly welcome.
comment: 29
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c29
Olli Pettay wrote on 2014-11-07 10:17:14 +0000.
(In reply to Hayato Ito from comment #28)
The nodes in the shadow tree of #c or #d would be in a composed tree (with document as root), since the host is such tree.
So the shadow dom would be "in composed document" (D).
comment: 30
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c30
Hayato Ito wrote on 2014-11-10 01:46:23 +0000.
No, the actual is:
c (or #d) is not in the composed tree (with document as root).
These nodes are child nodes of the shadow host (#a), however, they are not distributed at all.
However, #c (or #d) is "in a document".
A "composed document" (D) might be a good name for D, but I'm afraid that it is confusing name for D because #c (or #d) must belong to D, but #c (or #d) is not in the composed tree (with document as root).
I think "composed document" might be a good name for "C", "composed tree (with document as root), rather.
comment: 31
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c31
Hayato Ito wrote on 2014-11-10 01:49:24 +0000.
A small correction. #c is actually distributed, but it is not in a composed tree (with document as root) because the destination insertion point of #c is in the oldest shadow tree, which is disconnected.
(In reply to Hayato Ito from comment #30)
comment: 32
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c32
Hayato Ito wrote on 2014-11-10 02:10:52 +0000.
I forgot to express my opinion. The shadow trees hosted by #c (or #d) should be in category D. However, I might change my mind. That's hard for me to categorize it.
This might be a minor issue. What do you think?
Let me make a formal definition for D. That might be helpful for the discussion. I hope a formal definition would help me to understand the problem.
comment: 33
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c33
Hayato Ito wrote on 2014-11-10 04:23:13 +0000.
How about the following definition for category D?
A node, |A|, is 'in a document deeply' (a tentative name until we have a better one) if |A| meets at least one of the following conditions:
comment: 34
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c34
Hayato Ito wrote on 2014-11-10 06:08:11 +0000.
Yet another idea:
A node, |A| is 'in a document deeply' if |A| is inclusive deep descendant 1 of a document.
That would make things simpler, doesn't that?
comment: 35
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c35
Olli Pettay wrote on 2014-11-10 13:25:26 +0000.
(In reply to Hayato Ito from comment #32)
comment: 36
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c36
Hayato Ito wrote on 2014-11-11 06:32:07 +0000.
Thanks. If we agree that we should include shadow trees hosted by #c in 'D' (aka 'in a document deeply), I am wondering what is the difference between:
and
Any node in either tree isn't used in rendering at all (aka they are not in the composed tree (with document as root)), however,
That looks inconsistent to me.
Now I am thinking that the proposal in comment #34 is more consistent and even better than the proposal in comment #33 in most cases.
You can see the difference between the two proposals bellow (in the summary). Node #f and #g, which are in the oldest shadow tree, are the difference.
Here is the rationale why I thought proposal 2 (comment #34) is helpful than proposal 1 (comment #33):
I think 'nodes aren't contributing rendering' doesn't matter here because it's like a node with display: none in a document.
My design principle of shadow trees so far is that shadow trees are mainly used to construct one dom tree so that we can separate different concerns to each shadow trees.
Each node in shadow trees are 'in a document', conceptually. Although some nodes don't participate in the composed tree after the composition algorithm, I think we should consider such nodes like a node marked with 'display: none'. That's still in the document (conceptually, again).
Note that if we try to consider the nodes which doesn't participate in the composed tree are not 'in a document deeply', that will fail because node #c (or #d) is in a document, but it doesn't participate in the composed tree (with document as root). We can't adapt this idea because it would break backward-compatibility.
The summary is:
Proposal 1 (in comment #33):
A node, |A|, is 'in a document deeply' if |A| meets at least one of the following conditions:
The result would be:
(We use the example tree of trees in comment #21 again here. In addition to that, suppose that #c hosts a shadow tree, which contains the node |q|)
A). In a document x x x x x
B). In a shadow tree x x x x x x x x x X X
C). In a composed tree (root is a document) x x x x x
D). In a document deeply x x x x x x x x x x x x X
E). Disconnected (from D) x x x x
Proposal 2 (in comment #34):
A node, |A| is 'in a document deeply' if |A| is inclusive deep descendant 1 of a document.
The result would be:
A). In a document x x x x x
B). In a shadow tree x x x x x x x x x X X
C). In a composed tree (root is a document) x x x x x
D). In a document deeply x x x x x x x x x x x x x x X
E). Disconnected (from D) x x
If you find any mistake on this summary or any other ideas, please let me know that.
I'd like to make a decision and add the definition of 'in a document deeply' (a better name is still wanted) in the spec.
comment: 37
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c37
Olli Pettay wrote on 2014-11-11 12:22:18 +0000.
(In reply to Hayato Ito from comment #36)
comment: 38
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c38
Hayato Ito wrote on 2014-11-12 04:46:36 +0000.
(In reply to Olli Pettay from comment #37)
This is exactly what I thought when I saw your comment in #27.
After that, I've changed my mind because I found the inconsistency, as I explained in comment #36.
Could you have a closer look at comment #36? I'd like to understand why you don't think this is inconsistent.
It's not reasonable if we exclude only such an older shadow root, while including the shadow tree hosted by #c only for the reason that one is an older shadow tree and one is the youngest shadow tree.
Both shadow trees are in the same category in a sense that neither contribute to the document-rooted composed tree at all.
Basically, I think the distribution result shouldn't have any effect to 'in a document'-ness.
'In a document'-ness should be purely determined by the structure of the tree of trees.
In other words, adding/removing a element somewhere in the tree of trees shouldn't have any effect of 'in a document'-ness for other nodes in the tree of trees.
I guess there are two different kind of views for 'in a document'-ness in the shadow dom world.
A). Focusing a static structure of a tree of trees.
B). Focusing a dynamic structure. That's the document-rooted composed tree, which is the result of the distribution algorithm and the composition algorithm.
I think you have been focusing on B, but I'd like to focus on A here.
B will be likely to cause an inconsistency and make things complex. Unless we can find a serious issue in A, I'd like to go for A here.
Yeah, I shouldn't have omitted 'as long as the host is in a document deeply' here.
comment: 39
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c39
Boris Zbarsky wrote on 2014-11-12 10:05:10 +0000.
This comes down to questions like whether a non-distributed <iframe> should load its document, whether a non-distributed <style> should affect the styles of nodes, whether a non-distributed should load a stylesheet, whether a non-distibuted that was at one point distributed should continue running the plugin it loaded, whether a media element that stops being distributed should pause, whether non-distributed form controls should associate to forms, what should happen with showModal on a non-distributed , whether a <script> inserted under a non-distributed node should run, etc.
Note that it might turn out that the answers are different in those various different situation, in that some of them want non-distributed elements to act as if they were in a document and others don't...
comment: 40
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c40
Olli Pettay wrote on 2014-11-12 15:13:49 +0000.
(In reply to Hayato Ito from comment #38)
'in a document' -ness doesn't affect to the distribution.
Perhaps I should rephrase a bit. It is not only about the in-a-document, but about the composed tree rooted to a host
(and if that host is in document, that composed tree is in a composed tree which has document as root.).
However, I think I could live with A too. I'm certainly not strongly against it :)
But let me think this a bit, like this evening.
comment: 41
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c41
Olli Pettay wrote on 2014-11-12 17:45:22 +0000.
So I think if one overrides existing shadow dom of an element without
providing shadow insertion point for the old shadow tree, I would expect the
elements in that older shadow tree to stop behaving as if they where
still in document. Say, you have an <iframe> there, and the younger
shadow tree just wants to override all that with something more lightweight
(and not provide ). I think the <iframe> should be unloaded as if it was
removed from document.
If one wants to keep the old stuff working, then just explicitly provide shadow insertion point.
And still, I could live with (A), but it feels a bit odd to keep the older
shadow working while one probably wants to override it all with something else.
c case is different. There you have an element #c which is in document already.
(so if #c is an iframe, it does load a new document). So if you know create a shadow root for #c and insert <iframe> to it, why wouldn't it load.
comment: 42
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c42
Olli Pettay wrote on 2014-11-12 18:21:42 +0000.
Though, there is then the issue that if
the old shadow dom has <iframe> and a new one is created, before the
new one has any content, the <iframe> from the older one would be unloaded.
To make that work properly there should be a way to create a shadow dom with one function call.
Something like
element.createShadowRoot("<iframe></iframe>I'm in shadow dom");
or
element.createShadowRoot(someOtherElementWhichWillBeAppendedToTheShadowRoot);
comment: 43
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c43
Hayato Ito wrote on 2014-11-13 07:27:32 +0000.
(In reply to Olli Pettay from comment #41)
Yeah, that's a good point and that's one of the potential issue in idea A.
I think the concern comes from the fact that there is no way to get rid of the existing old shadow trees completely from the shadow host in the current API set of Shadow DOM.
The reason we don't have such an API is that I've not heard the requirement for the removal, AFAIK.
I guess much attention has not been paid to such a wasteful resource, which would be consumed by overridden shadow trees, because that's a rare use case.
I'm okay to add such an API if this would be a non-ignorable use case and developers would start to complain about this kind of wastefulness.
(In reply to Boris Zbarsky from comment #39)
Yeah, that's a good point. That should be always on my radar, however, it seems I forgot to mention that in my recent posts.
The basic idea in my head is:
For example:
Of course, there should be a exception. For example, the current spec disables the capability of the and elements in shadow trees as if they were in a document fragment. The answers should be different in those various different situation as you mentioned.
I'd expect the my basic idea covers the most cases, hopefully.
comment: 44
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c44
Olli Pettay wrote on 2014-11-13 11:27:34 +0000.
(In reply to Hayato Ito from comment #43)
Yeah, ok, perhaps (A) for this case, and possibly add
createAndReplaceExistingShadowRoot() in the future.
comment: 45
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c45
Boris Zbarsky wrote on 2014-11-13 16:32:48 +0000.
This is the part that's non-obvious to me, frankly. I mean, obviously if we treat them as being in a document they should be treated the same way as display:none. But the premise that they should be treated as in a document is not a given.
What's needed is a concrete list of those exceptions (in either direction). Starting with the list Chrome implements would be a good start, say, because then we at least have something to discuss.
comment: 46
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c46
Hayato Ito wrote on 2014-11-14 08:00:45 +0000.
Yeah, I think it's time to take a closer look at each case.
For example, in the HTML Living Standard, #in-a-document is referenced in:
2.1.3 DOM trees
3.1.3 DOM tree accessors
4.2.6 The style element
4.2.7 Interactions of styling and scripting
4.6.5.14 Link type "stylesheet" (2) (3) (4) (5)
4.8.5 The img element
4.8.7 The embed element (2)
4.8.8 The object element
4.8.14.8 Playing the media resource (2)
4.8.14.11.3 Assigning a media controller declaratively
4.10.18.3 Association of controls and forms (2)
4.10.19.8.3 User interface for bulk autofill
4.11.6.1 Facets
4.11.7 The dialog element
4.12.1 The script element (2) (3)
6.2 Inert subtrees
6.5.3 Processing model
7.1.1 Nested browsing contexts (2)
7.2.3 Accessing other browsing contexts (2)
15.3.1 The applet element
15.3.3 Frames
I've taken a quick look at each usage:
4.2.6 The style element
4.2.7 Interactions of styling and scripting
4.6.5.14 Link type "styleseet"
4.8.5 The img element
4.8.6 The iframe element
4.8.7 The embed element
4.8.8 The object element
4.8.14.8 Playing the media resource
4.8.14.11.3 Assigning a media controller declaratively
4.10.18.3 Association of controls and forms
4.10.19.8.3 User interface for bulk autofill
4.11.6.1 Facets
4.11.7 The dialog element
4.12.1 The script element
6.2 Inert subtrees
6.5.2 The accesskey attribute
6.5.3 Processing model
7.1.1 Nested browsing contexts
7.2.3 Accessing other browsing contexts
8.1.5.4 Events and the Window object
15.3.1 The applet element
15.3.3 Frames
In addition to 'in a Document', I think we need to have better words in replace of 'inserted into a document' and 'removed from a document' in some places.
'inserted into a document' is referenced in:
4.2.5.3 Pragma directives (2)
4.2.6 The style element
4.6.5.14 Link type "stylesheet"
4.8.6 The iframe element
4.8.8 The object element
4.10.18.3 Association of controls and forms (2)
4.10.19.6.1 Autofocusing a form control: the autofocus attribute (2)
4.12.1 The script element (2)
7.6.3 Page load processing model for XML files (2)
8.1.4.1 Definitions
8.1.4.3 Generic task sources
'removed from a document' is referenced in:
4.2.6 The style element
4.8.6 The iframe element
4.8.8 The object element
4.8.14.8 Playing the media resource
4.8.14.19 Best practices for implementors of media elements
4.10.18.3 Association of controls and forms
4.11.7 The dialog element
Note that this is just a quick check. I have to do take another closer look in the next iteration.
comment: 47
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c47
Hayato Ito wrote on 2014-11-14 08:18:10 +0000.
Here is the filed chrome bugs:
I think the intentional exception in the current blink's implementation is and elements. See 7.1 Inert HTML Elements: http://w3c.github.io/webcomponents/spec/shadow/#inert-html-elements
I think the paragraph in the Shadow DOM spec:
must be updated. Further more, we can remove this 7.1 section from the Shadow DOM spec if we finish all tasks here, hopefully.
comment: 48
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c48
Hayato Ito wrote on 2014-11-19 05:09:26 +0000.
*** Bug 25562 has been marked as a duplicate of this bug. ***
comment: 49
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c49
Hayato Ito wrote on 2014-11-19 07:47:31 +0000.
I've defined 'in a document deeply' (as a tentative name) in the Shadow DOM spec.
7b4bdc8
Now it's time to take a closer look at each case. I think <style> 1 is a good starter case for us.
Should we file a bug for HTML living standard 2 for each case and continue discussion there for each case?
If there is a need to discuss something in general further, we could use this thread anytime.
1 https://html.spec.whatwg.org/multipage/semantics.html#the-style-element
2 https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=HTML&list_id=47544&product=WHATWG
comment: 50
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c50
Boris Zbarsky wrote on 2014-11-19 14:34:31 +0000.
That seems like a good idea, yes.
comment: 51
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c51
Dimitri Glazkov wrote on 2014-11-19 15:46:46 +0000.
(In reply to Boris Zbarsky from comment #50)
Another thing that I ran by Hixie is just creating a patch against the HTML spec mirror (https://github.com/whatwg/html-mirror) -- if that's more lightweight.
comment: 52
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c52
Hayato Ito wrote on 2014-11-20 07:22:10 +0000.
(In reply to Dimitri Glazkov from comment #51)
Thanks. I like it. It's a convenient way for me to create a patch, on which we could discuss.
comment: 53
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c53
Ian 'Hixie' Hickson wrote on 2014-11-21 23:25:51 +0000.
Thanks for the list above, Hayato.
When considering these, one should also consider:
In general, I think we want to have as few categories of elements here as possible. In particular, I think "being rendered vs not being rendered", "in the document deeply vs not", "in the document directly vs not", and "scoped to the current subtree" are reasonable categories.
So it seems to me that for the above we should go as follows:
"In the document":
(e.g. you don't want rel=import working from inside a shadow tree)"Being rendered":
focusable
"Scoped to the current subtree":
media controllers
form control associations
"In the document deeply":
<script> exposure accesskey autofocus <iframe>, window.length inertness of browsing context container <style>The text was updated successfully, but these errors were encountered: