This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
# 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;
Perhaps something along the lines of LayoutRoot?
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?
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.
Thank you for the explanation. I understand. Only Document and ShadowRoot contribute to Layout Tree. That's true! +1 for LayoutRoot.
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.
Moved to https://github.com/w3c/webcomponents/issues/91