Component Model

The applyAuthorSheets attribute indicates whether or not rules in author style sheets associated with the element's document apply to the shadow DOM subtree. It is an equivalent of the XBL2 apply-author-sheets attribute.

The shadowHost attribute refers back to the element that is hosting this shadow root.

The parentTreeScope attribute returns the tree scope that contains this tree scope.

The getElementById returns first element, in tree order, within the tree scope's tree, whose ID is elementId. It is essentially document.getElementById from DOM Core, but scoped inside of the tree scope.

The pseudo attribute allows setting a CSS pseudo-element value on an element and roughly corresponds to functionality of the XBL2 pseudo attribute. 43 | 44 | 47 | 48 | The value must either be null or a string that matches the IDENT production of the CSS grammar, with the exception that the names defined by CSS for pseudo class selectors and pseudo element selectors are not valid, for example: active, after, before, checked, disabled, empty, enabled, first-child, first-letter, first-line, first-of-type, focus, hover, indeterminate, lang, last-child, last-of-type, link, not, nth-child, nth-last-child, nth-last-of-type, nth-of-type, only-child, only-of-type, root, target, visited. 49 | -------------------------------------------------------------------------------- /events.html: -------------------------------------------------------------------------------- 1 | 2 | 25 | 26 |

Event Retargeting

When an event is fired in a shadow DOM subtree, it either escapes out of the shadow tree during the capture, target, bubble, or default phases or it is stopped at the shadow boundary.

To help with algorithm description, let's define the direction walking the ancestors of a node as up when traversing from child to parent, and down when traversing from parent to child. In the context of events-related algorithms, all ancestor traversal crosses shadow boundaries.

In the cases where event escapes the shadow tree, the event is retargeted to ensure that the original target-related information on the event object does not reveal information about the shadow DOM subtree beyond the boundary. Event retargeting is a process of computing a relative target for each ancestor of the node at which the event is dispatched.

41 |

Set the relative target of the node at which event is fired to the node itself.
For each ancestor walking up starting with the node's parent, compute its relative target:
44 |
1. If the node is a shadow boundary, skip it
2. If the previous node was a shadow boundary, make the node its own relative target.
3. Otherwise, use previous node's relative target.
49 |

51 |

At the time of event dispatch, for capturing, target, and bubbling phases, Event object's target and currentTarget must be set to the relative target that was computed for the node along the capturing and bubbling flow.

Upon completion of the event dispatch, the Event object's target and currentTarget are set to the highest ancestor's relative target. Since it is possible for a script to hold on to the Event object past the scope of event dispatch, this step is necessary to avoid revealing the nodes in shadow DOM subtrees.

Related Target Events

Some events have a relatedTarget property, which holds a node that's not the event's target, but is related to the event. For instance, a mouseover event's relatedTarget may hold the node from which the mouse has moved to event's target. In the case where relatedTarget is in a shadow DOM subtree, we don't want to leak its actual value outside of this subtree. In cases where both relatedTarget and target are part of the same shadow DOM subtree, we don't want the appearance of spurious mouseover and mouseout events firing from the same node.

Thus, if an event has a relatedTarget, its value and extent of event dispatch must to be adjusted. In general: 66 |

73 |

Find the lowest common ancestor of target and relatedTarget.
If there is none, skip to step 7 in the algorithm.
If the lowest common ancestor is relatedTarget, and it's a shadow DOM subtree host, make this tree's boundary the lowest common boundary, and go to step 6 in the algorithm.
Looking at the ancestors of the lowest common ancestor, starting at its parent and walking up, find a shadow boundary. This is the lowest common boundary, the boundary of a shadow DOM subtree that encloses both target and relatedTarget. 78 |
If the lowest common boundary is not found, skip to step 7 in the algorithm.
Limit event dispatch to the descendants of the lowest common boundary.
If the lowest common boundary is still undetermined at this point, set it to be the farthest ancestor of the relatedTarget.
Starting from lowest common boundary and walking down ancestors of the relatedTarget, find a shadow boundary. This is the first divergent boundary.
If first divergent boundary is not found, stop.
Set relatedTarget to the parent of the first divergent boundary. 84 |

85 |

Focus Events

The focus, DOMFocusIn, blur, and DOMFocusOut events must be treated in the same way as events with a relatedTarget, where the corresponding node that is losing focus as a result of target gaining focus or the node that is gaining focus, and thus causing the blurring of target acts as the related target. 90 | 91 |

Events That Are Always Stopped

Mutation events and selectstart event are always stopped at the nearest shadow boundary.

Example

Suppose we have a user interface for a media controller, built with several components, represented by this shadow-aware DOM tree:

Let's have a user position their pointing device over the volume slider's thumb (#player::volume-slider::slider-thumb), thus triggering a mouseover event on that node. For this event, let's pretend it has no associated relatedTarget.

At the end of this process, we should have the following set of ancestors and relative targets:

Ancestor	Relative Target
`...`	`div#player`
`div#player`	`div#player`
`div#player::controls`	`div#player::controls::volume-slider`
`div#player::volume-slider-container`	`div#player::controls::volume-slider`
`div#player::controls::volume-slider`	`div#player::controls::volume-slider`
`div#player::controls::volume-slider::slider-thumb`	`div#player::controls::volume-slider::slider-thumb`

After we dispatch the mouseover event using these newly computed relative targets, the user decides to move their pointing device over the thumb of the timeline (#player::timeline::slider-thumb). This triggers both a mouseout event for the volume slider thumb and the mouseover event for the timeline thumb.