Shared mixin for Document and ShadowRoot

[hayatoito]

Title: [Shadow]: Have a common interface between Document and ShadowRoot (bugzilla: 28493)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c0
Hayato Ito wrote on 2015-04-15 06:37:12 +0000.

This is separated from https://www.w3.org/Bugs/Public/show_bug.cgi?id=27829#c2

Instead of defining these in Shadow Root as well as in Document, I've started to feel that it'd be better that we have the common interface between Document and Shadow Root.

e.g.

    interface NodeTreeRoot {
      Element? elementFromPoint(double x, double y);
      sequence<Element> elementsFromPoint(double x, double y);
      CaretPosition? caretPositionFromPoint(double x, double y);
      Selection? getSelection ();
      readonly    attribute Element?       activeElement;
      readonly    attribute StyleSheetList styleSheets;
    };


    Document implements NodeTreeRoot;
    ShadowRoot implements NodeTreeRoot;

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c1
Anne wrote on 2015-04-15 08:22:32 +0000.

Perhaps something along the lines of LayoutRoot?

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c2
Hayato Ito wrote on 2015-04-15 09:27:47 +0000.

Thank you.

BTW, in Blink, we use a term of TreeScope for this purpose, at least in C++.
Both Document and ShadowRoot implements TreeScope.

(In reply to Anne from comment #1)

Perhaps something along the lines of LayoutRoot?

So the candidates are:

• NodeTreeRoot
• LayoutRoot
• TreeScope

Any other better idea?

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c3
Anne wrote on 2015-04-15 09:32:58 +0000.

TreeScope and NodeTreeRoot both have the problem that their terminology also applies to Element and DocumentFragment.

What's special about ShadowRoot and Document is that they are layout/CSS/stylesheet boundaries.

---

comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c4
Hayato Ito wrote on 2015-04-15 11:29:25 +0000.

Thank you for the explanation. I understand. Only Document and ShadowRoot contribute to Layout Tree. That's true!

+1 for LayoutRoot.

---

comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28493#c5
Tab Atkins Jr. wrote on 2015-04-15 16:44:38 +0000.

I used the name "TreeScope" in http://tabatkins.github.io/specs/construct-stylesheets/#adding-stylesheets.

But Anne's comments make some sense. I'm fine with LayoutRoot.

[hayatoito]

I've filed a bug to HTML: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28748

[hayatoito]

We might want to resolve this issue when we upstream Shadow DOM into {DOM/HTML} Standard.
Let me label this issue with v2.

[annevk]

What do you think about Component as mixin name? It seems that is the terminology Shadow DOM settled on at the moment and it seems fine to me. (LayoutRoot, while nice, doesn't work since it's not really about layout.)

Paging @rniwa and @domenic for bikeshed input.

[hayatoito]

Component sounds good to me.

Yeah, Shadow DOM spec has started to use component tree as either of a document tree or a shadow tree, roughly, recently. I could not come up any better name other than that.

[rniwa]

I don't like Component. That's such an overloaded term.

[rniwa]

How about PrimaryTreeRoot if we're going with the terminology of primary tree to refer to a document tree or a shadow tree?

[annevk]

Every node on its own is a "tree root". And speaking of overloaded terms, what about Text, Document, Node, etc.? This would at least let us keep the term "components" in this whole setup somehow.

[rniwa]

@annevk Then we should come up with a different word. I would strongly object to using the term "component" in this manner.

[annevk]

It's just a mixin, it isn't even exposed to script. And we don't really use "component" anywhere else as far as I know. I can't quite think of a good alternative.

[rniwa]

I would still be strongly opposed to this terminology creeping into various specifications.

[annevk]

I see. What about DocumentOrShadowRoot?

[annevk]

(That doesn't really solve the problem of what we'd call that type of tree though.)

[annevk]

Though given that in the specification today "component tree" is equivalent to "node tree", perhaps we can work around that. Not sure. Need to study it more.

[rniwa]

DocumentOrShadowRoot would work. At the end of the day, that might be the most descriptive name. I'd prefer saying exactly what it is instead of making up a new term.

[annevk]

Okay, so the DOM Standard will define the DocumentOrShadowRoot mixin. Then HTML and CSSOM will extend the mixin using "partial" with their respective features (and make sure those features are defined properly for ShadowRoot objects).

[hayatoito]

+1. DocumentOrShadowRoot would work. I do not have any better name idea.

[annevk]

Added to DOM. Shadow DOM specification can now make use of it.