Ranges and Selections

Selection [[!EDITING]] is not defined. Implementation should do their best to do what's best for them. Here's one possible, admittedly naive way:

Since nodes which are in the different node trees never have the same root, there may never exist a valid DOM range that spans multiple node trees.

Accordingly, selections may only exist within one node tree, because they are defined by a single range. The selection, returned by the window.getSelection() method never returns a selection within a shadow tree.

The getSelection() method of the shadow root object returns the current selection in this shadow tree.

Assistive Technology

User agents with assistive technology traverse the flat tree, and thus enable full use of WAI-ARIA [[!WAI-ARIA]] semantics in the shadow trees.

Hit Testing

When a text node is a child node of a shadow root, a hit testing must target the shadow host if the text node is the result of the hit testing.

User-agent mouse events must be targeted to the parent node in the flat tree of a text node if the topmost event target is the text node.

This section eventually needs to be part of some general hit testing specification.

Inertness of HTML Elements in a shadow tree

Comparatively, a shadow tree can be seen as somewhere between just part of a document and itself being a document fragment. Since it is rendered, a shadow tree aims to retain the traits of a typical tree in a document. At the same time, it is an encapsulation abstraction, so it has to avoid affecting the document tree. Thus, the HTML elements must behave as specified [[!HTML]] in the shadow trees, with a few exceptions.

According to the [[!HTML]], some HTML Elements would have different behavior if they participate in a shadow tree, instead of a document tree, because their definitions require the elements to be in a document as a necessary condition for them to work. In other words, they shouldn't work if they participate in a shadow tree, even when they are in a shadow-including document. We must fill this gap because we expect that most of HTML Elements behave in the same way as in a document, as long as they are in a shadow-including document. See W3C Bug 26365 and Bug 27406 for the details. The following is the tentative summary of the discussions in the W3C bugs. We, however, haven't covered all HTML Elements and their behaviors here yet. For HTML Elements which are not explicitly stated here, they should *work* even in a shadow tree. We are trying to update [[!HTML]] itself, instead of having monkey patches here. If [[!HTML]] explains an element's behavior explicitly, it should be honored, instead of this section.

Some HTML Elements are classified into the following categories:

• Inert in a shadow tree:

  A subset of HTML elements which must behave as inert, or not part of the document tree, if they participate in a shadow tree. This is consistent how the HTML elements would behave in a document fragment.

  The following HTML elements must be classified to this category:

  • base
  • link
  • meta

  <link rel="stylesheet"> is now supported in a shadow tree (HTML Standard). For other cases, the discussion is on-going at Issue #628.

• Inert unless being rendered:

  A subset of HTML elements which must behave as inert, or not part of the document tree, unless they are being rendered. In other words, if they don't participate in a document flat tree, they must behave as inert.

  The following HTML elements must be classified to this category:

  • applet
  • embed
  • object

  For example, suppose that an object element is a child node of a shadow host, but the object element is not assigned to a slot. In this case, according to the flat tree children calculation algorithm, this element never participate in a document flat tree. Therefore, this element is inert because this element is not being rendered. .

Attributes

When [[!HTML]] defines the processing algorithms to traverse trees for the following attributes, they must use the flat tree.

• dir
• draggable
• dropzone
• hidden
• lang and xml:lang
• spellcheck
• title

role and ARIA are defined in Assistive Technology.

Other Clarifications

This section is used to state what needs to be clarified. Each clarification will be upstreamed to the HTML Standard or other specifications, eventually, if required.

Style elements inside a shadow tree must not be able to set the preferred style sheet set for the document tree. Style elements inside a shadow tree should still be applied if it has a title attribute not matching the preferred style sheet set of the document tree. See Issue #391.

An iframe in a shadow tree must not have any effect on window.history neither window.frames. See Issue #184.

:root pseudo class does not match any element if the rule is used in a shadow tree.

Extensions to the DocumentOrShadowRoot Mixin

          partial interface DocumentOrShadowRoot {
            Selection? getSelection ();
            Element? elementFromPoint(double x, double y);
            sequence<Element> elementsFromPoint(double x, double y);
            CaretPosition? caretPositionFromPoint(double x, double y);
          };
        

• These methods and attributes are defined in the similar way as currently defined in Document, considering only the current node tree.
• Regarding elementFromPoint and elementsFromPoints, they should return the result of running the retargeting algorithm with context object and the original result as input.
• We should remove these methods and attributes from Document when this section is upstreamed.