'in a Document' for shadow trees

[hayatoito]

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.

such as 'in a Document or in a shadow tree'

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)

such as 'in a Document or in a shadow tree'

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?

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)

Yes, but what will break if the definition of "in a Document" is changed to
mean that (with s/element/node/, I assume).

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.

That should be no impact, I hope.

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)

That should be no impact, I hope.

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.

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:

1. A node is In a Document.
2. A node is *in a composed tree whose root is a Document.
3. A node is In a Document, but not in a composed tree whose root is a Document.
   (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)

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"

For example, the following codes could be in (3), but not in (4):

• A node is a child node of a shadow host, but the node is not distributed to any insertion points.
• A node is in the older shadow tree, but the younger shadow tree doesn't have element.
• A node is a child of content insertion points.

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.

For example, the following codes could be in (3), but not in (4):

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)

First step here seems to me to be to enumerate all the cases we care about.

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)

For example, the following codes could be in (3), but not in (4):

• A node is a child node of a shadow host, but the node is not distributed
  to any insertion points.
• A node is in the older shadow tree, but the younger shadow tree doesn't
  have element.
• A node is a child of content insertion points.

These nodes couldn't participate in the composed tree.

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)

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.

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:

1. 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.

2. Go though specs and file bugs.

   • Which specs should we take care of? DOM and HTML and... maybe all?
   • Should we manage the list of relevant bugs in W3c bugzilla?
     e.g. One master (meta) bug and other relevant bugs which depends on the meta-bug.

3. Use our best judgement and update the spec in each filed bug.

(In reply to Ian 'Hixie' Hickson from comment #18)

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: 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:

1. oldest-shadow-root

   // #older-shadow-root doesn't have a shadow insertion point.

2. older-shadow-root

3. 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 b c d e f g h i j k l m n o p

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

D). In a tree of trees (root is a document) x x x x x x x x x x x x x x

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)

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?

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)

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: 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:

• |A| is in a document
• |A| is in the youngest shadow tree, |T|, and the shadow host which hosts |T| is 'in a document deeply'
• |A| is in an older shadow tree, |T|, and the younger shadow tree relative to |T| has a shadow insertion point, |I|, and |I| is 'in a document deeply'

---

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)

I forgot to express my opinion. The shadow trees hosted by #c (or #d) should
be in category D.
So we agree here. I said (D) in comment 29.

---

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:

• the shadow tree hosted by #c
  and
• the oldest shadow tree in the example.

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,

• Nodes in the shadow tree hosted by #c are 'in a document deeply',
• Nodes in the oldest shadow trees, such as #f and #g, are not 'in a document deeply'.

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:

• |A| is in a document
• |A| is in the youngest shadow tree, |T|, and the shadow host which hosts |T| is 'in a document deeply'
• |A| is in an older shadow tree, |T|, and the younger shadow tree relative to |T| has a shadow insertion point, |I|, and |I| is 'in a document deeply'

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 b c d e f g h i j k l m n o p 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 b c d e f g h i j k l m n o p 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 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)

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:

• the shadow tree hosted by #c
  and
• the oldest shadow tree in the example.

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,

• Nodes in the shadow tree hosted by #c are 'in a document deeply',
• Nodes in the oldest shadow trees, such as #f and #g, are not 'in a
  document deeply'.

That looks inconsistent to me.
Not to me.
In my mind only the youngest shadow tree is in the documented rooted composed tree if the host is in document rooted composed tree.
Older shadow trees are in document rooted composed tree only if they are attached to a shadow insertion point which is in
a document rooted composed tree.
I think this would be a quite simple way to spec this

I think 'nodes aren't contributing rendering' doesn't matter here because
it's like a node with display: none in a document.
true

Each node in shadow trees are 'in a document', conceptually.
Not quite, since the host might not be in a document.

---

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)

(In reply to Hayato Ito from comment #36)

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:

• the shadow tree hosted by #c
  and
• the oldest shadow tree in the example.

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,

• Nodes in the shadow tree hosted by #c are 'in a document deeply',
• Nodes in the oldest shadow trees, such as #f and #g, are not 'in a
  document deeply'.

That looks inconsistent to me.
Not to me.
In my mind only the youngest shadow tree is in the documented rooted
composed tree if the host is in document rooted composed tree.
Older shadow trees are in document rooted composed tree only if they are
attached to a shadow insertion point which is in
a document rooted composed tree.

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.

Each node in shadow trees are 'in a document', conceptually.
Not quite, since the host might not be in a document.

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)

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.
Why it is not reasonable?

Both shadow trees are in the same category in a sense that neither
contribute to the document-rooted composed tree at all.
Well, youngest tree does always contribute to the composed tree of rooted by its host.
Older, not distributed to any shadow insertion points are different.

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 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.).

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'm thinking about B) and how event handling and such behave in the whole setup.

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)

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.

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)

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...

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:

• We should treat such elements so that we got the equivalent result to "They were in a document (in a traditional meaning), but it is marked 'display: none'.

For example:

• As for <script> element, we have to run the <script> 'in a document deeply, but not in the document-rooted composed tree', as long as <script> in a document runs even if it is marked with 'display: none'.
• As for <iframe> element, we have to load the resources from <iframe> 'in a document deeply, but not in the document-rooted composed tree' as long as <iframe> 'in a document' loads resources even if this is marked with 'display: none'.

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)

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.

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.

• We should treat such elements so that we got the equivalent result to "They
  were in a document (in a traditional meaning), but it is marked 'display: none'.

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.

Of course, there should be a exception.

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

If element is not in a Document, then abort these steps.

4.2.7 Interactions of styling and scripting

... last time the event loop reached step 1, the element was in that Document, and the user agent hasn't given up on that particular style sheet yet.

4.6.5.14 Link type "styleseet"

When the external resource link is created on a link element that is already in a Document.

4.8.5 The img element

While a user agent is running the above algorithm for an element x, there must be a strong reference from the element's node document to the element x, even if that element is not in its Document.

4.8.6 The iframe element

For example if the user agent supports listing all the links in a document, links in "seamlessly" nested documents would be included in that list without being significantly distinguished from links in the document itself.

4.8.7 The embed element

... The element is in a Document or was in a Document the last time the event loop reached step 1.

4.8.8 The object element

... If the element has an ancestor media element, or has an ancestor object element that is not showing its fallback content, or if the element is not in a Document with a browsing context, o

4.8.14.8 Playing the media resource

.. Media elements that are potentially playing while not in a Document must not play any video, but should play any audio component.

4.8.14.11.3 Assigning a media controller declaratively

If there is another media element whose Document is the same as m's node document (even if one or both of these elements are not actually in the Document), and which also has a mediagroup attribute, and whose mediagroup attribute has the same value as the new value of m's mediagroup attribute, then let controller be that media element's current media controller.

4.10.18.3 Association of controls and forms

... If the element is reassociateable, has a form content attribute, and is itself in a Document, then run these substeps:

4.10.19.8.3 User interface for bulk autofill

... form is no longer in a Document

4.11.6.1 Facets

The element is in a Document that has an associated browsing context.

4.11.7 The dialog element

If subject is not in a Document, then throw an InvalidStateError exception and abort these steps.

4.12.1 The script element

The script element is in a Document and a node or document fragment is inserted into the script element, after any script elements inserted at that time.
The script element is in a Document and has a src attribute set where previously the element had no such attribute.

6.2 Inert subtrees

While a browsing context container is marked as inert, its nested browsing context's active document, and all nodes in that Document, must be marked as inert.

6.5.2 The accesskey attribute
6.5.3 Processing model

When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, the command's Hidden State facet is false (visible), the command's Disabled State facet is also false (enabled), the element is in a Document

7.1.1 Nested browsing contexts

Certain elements (for example, iframe elements) can instantiate further browsing contexts. These are called nested browsing contexts. If a browsing context P has a Document D with an element E that nests another browsing context C inside it, then C is said to be nested through D, and E is said to be the browsing context container of C. If the browsing context container element E is in the Document D

7.2.3 Accessing other browsing contexts

The length IDL attribute on the Window interface must return the number of child browsing contexts that are nested through elements that are in the Document that is the active document of that Window object,

8.1.5.4 Events and the Window object

When an event is dispatched at a DOM node in a Document in a browsing context, if the event is not a load event, the user agent must act as if, for the purposes of event dispatching, the Window object is the parent of the Document object. [DOM]

15.3.1 The applet element

The element is not in a Document.

15.3.3 Frames

A frame element is said to be an active frame element when it is in a Document.

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:

• iframe: https://code.google.com/p/chromium/issues/detail?id=393350
• script: https://code.google.com/p/chromium/issues/detail?id=394327
• accesskey: https://code.google.com/p/chromium/issues/detail?id=394295
• label: https://code.google.com/p/chromium/issues/detail?id=394307
• doucment.currentscript: https://code.google.com/p/chromium/issues/detail?id=394332
• attachedCallback (custom elements): https://code.google.com/p/chromium/issues/detail?id=426050

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:

7.1 Inert HTML Elements
All other HTML elements in the shadow trees must behave as if they were part of the document tree.

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.

Should we file a bug for HTML living standard 2 for each case

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)

Should we file a bug for HTML living standard 2 for each case

That seems like a good idea, yes.

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)

(In reply to Boris Zbarsky from comment #50)

Should we file a bug for HTML living standard 2 for each case

That seems like a good idea, yes.

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.

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:

• a node A that's a child of an element that has a shadow tree that doesn't have an insertion point for A.
• a node A that's a grandchild of an element that has a shadow tree that doesn't have an insertion point for A.
• a node that's in a shadow tree of an element B that itself is a child of an element with a shadow tree that doesn't have an insertion point for B.
• a node that is display:none.
• an orphan node.
• a node in a shadow tree of an orphan node.
• a node that is being rendered
• a node that is not being rendered but that is in the composed tree

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>

[smaug----]

So what is happening with this. We need all the is-in-document cases resolved before we can have
interoperable implementations.
@rniwa , how is webkit dealing with these issues?

[smaug----]

@annevk

[rniwa]

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).

[smaug----]

Ok, so not following the current specs but doing something else.
(it is fine to not follow the current specs for now, since they clearly don't define what people want, but it is naturally not ok to ship code against the specs)

[smaug----]

label.htmlFor as an example is a case where we don't want shadow DOM to be treated as if it was in document
https://html.spec.whatwg.org/#attr-label-for
since that would end up leaking label inside shadow DOM to the outside world
(via labelableControl.labels)

[rniwa]

I think we need to update the HTML spec to respect the shadow boundary in those cases.

[smaug----]

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.

[hayatoito]

Ops. This migrated issue looks difficult to read. Please see the original discussion
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365 to follow the discussion.

In summary, this section in the spec reflects what we had agreed:
http://w3c.github.io/webcomponents/spec/shadow/#html-elements-in-shadow-trees

Please add any feedback to this section before upstreaming it to the HTML standard.
I'm afraid that this list is incomplete. We have to make this list complete so that we don't have an interoperability issue. If you find something missing, I'm happy to mention that in this section. Pull-Requests might be a quick way.

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".

[rniwa]

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 dialog element, and a sentence such as "must behave as inert, or not part of the document tree" doesn't make much sense as a spec text as it would mean that the node can behave either as if it didn't exist in the document tree or as if it's hidden by a dialog element. i.e. I don't think "inert" means what you think it means in the HTML spec.

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".

[hayatoito]

@rniwa
Regarding with "in a document", that's exactly what we had discussed in this thread and we agreed on that. I am happy to hear that you have the same opinion. "In a document" will stay on a purely DOM concern.

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.
I guess we might want to have another good well-defined terminology.

[smaug----]

We need to get some hooks to HTML spec which Shadow DOM spec then refers to or vice versa, or
merge Shadow DOM to DOM and put the DOM tree related terminology there and then HTML spec would use them. Anyhow something which let's the algorithms in the specs be written precisely.

And indeed, something being rendered or not shouldn't affect to any of this.

[smaug----]

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
(maybe so that in-document there starts to mean in-document or in a shadow dom attached to in-document host by default), but also includes checking whether getElementById call used by specs go through the shadow boundary or stuff like document.currentScript.

Anyone have some spare time?

CCing also
@adrianba

[annevk]

@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 document.currentScript do. I'm happy to do some work here, but it would be good to have agreement on what we want to do be doing.

[hayatoito]

Let me remove v1 label from all issues where there is no contentious bits.
Instead, let me use html-dom label tentatively so that we will address it in upstreaming the spec into HTML/DOM standard.

I would like to reduce the number of issues with v1 label so that we can focus on resolving contentious bits.

[tomalec]

I'm not sure if I get the discussion correctly. Do you have any agreement on how for example <script> element that is shadow host child (in , but is not distributed, should behave/be executed, or is the decision deferred until upstreaming the spec into HTML/DOM standard?

Should, it be executed as it is in document tree (=> "in Document")?
Currently, it works that way in Chrome, but webcomponentsjs polyfill works other wise, and I'm not sure weather it's a bug or desired behavior.

Sorry for flooding your topic with my issue reference, I was just quoting the spec.

[annevk]

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.