Re: shadow tree vs. shadow DOM

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 <mailto: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
> 
> 
> 
> 
>