Re: shadow tree vs. shadow DOM

There are no special DOM APIs for shadow dom nodes: they are just regular
nodes.  If an event (such as focus change) gives you a pointer to an
element in the shadow tree, you could access its attributes and event
handlers the same as any other element

The main limitation of the current APIs is in the discoverability of
elements: document.getElementById() or document.querySelectorAll() and so
on will not find elements in shadow trees. ID values are also not unique
across the composed document, which makes many ARIA properties problematic.





On 27 July 2016 at 08:16, Richard Schwerdtfeger <richschwer@gmail.com>
wrote:

> Thank you Amelia. Yes, please include the the links to refer to the event
> handling and also the DOM script API that is applicable to nodes in that
> tree. … e.g. apis for getting attributes including onclick handlers, etc .
>
> Rich
>
> On Jul 26, 2016, at 2:18 PM, Amelia Bellamy-Royds <
> amelia.bellamy.royds@gmail.com> wrote:
>
> Sorry all for missing the call this week. Wasn't watching the time.
>
> Fred also had this confusion when we were discussing my pull request last
> week, and I promised to try to clarify it in the SVG-AAM.  Unfortunately, I
> haven't gotten to that yet; still working on cleaning up the SVG 2 edits.
>
> Shadow DOM is the generic term for the concept, that you can have elements
> that are connected to the document, and rendered as part of the document,
> but not actually part of the node tree rooted in the document object.
> However, the term "Shadow DOM" does not have an explicit definition.  There
> is no "Shadow DOM" object.
>
> A shadow tree is a specific data structure, a node tree that has a
> ShadowRoot object as its root, where the ShadowRoot is associated with a
> "host" element in another tree.  The host element may itself be inside
> another shadow tree.
>
> Node trees that *aren't* shadow trees are either disconnected document
> fragments (the root is a DocumentFragment object) or document trees (the
> root is a Document object).  The final behavior of many elements depend on
> whether they are *connected* to a Document, either by being part of it's
> document tree or by being in a nested shadow tree.
>
> The Shadow DOM spec defines amendments to DOM 4 to cover event handling,
> bubbling and re-targetting in a document that includes shadow trees.  These
> changes are also being integrated directly in the WHATWG DOM spec, and any
> future W3C DOM spec will likely fork that text.
>
> The use of the term "shadow tree" refers automatically includes the event
> handling rules as defined in those specs.  I will add links to the terms to
> make it clear that we are using them in that sense.
>
> In the SVG-AAM I loosely referred to "shadow DOM content" a few times when
> I meant "nodes in a shadow tree" or specifically, "nodes in a use-element
> shadow tree"  (which is a term I define in SVG 2).  I will edit that to be
> more explicit, and/or to define a term that I can then reference as needed.
>
> Again, sorry I wasn't on the call to answer your questions directly.
>
> Best,
> Amelia
>
> On 26 July 2016 at 12:40, Rich Schwerdtfeger <richschwer@gmail.com> wrote:
>
>> Why does the SVG spec. and the mapping guide refer to a shadow tree?. I
>> believe it should be a shadow DOM. This is important as the DOM defines a
>> tree and it also defines how events bubble. We have no definition for  your
>> shadow “tree” does this.
>>
>> Please consider the use of the term “tree”.
>>
>> Note: web components also uses the term shadow DOM and similar
>> functionality is going on for web components in that id references are
>> scoped within the context of the web component or <use> href document
>> instance.
>>
>> Rich
>> Rich Schwerdtfeger
>>
>>
>>
>>
>>
>
>