22203 2013-05-30 07:00:26 +0000 [Shadow]: Define relationships between trees using terms of {child, parent, descendant, ancestor}. 2013-07-24 05:14:34 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 22716 1 hayato hayato public-webapps-bugzilla oldest_to_newest 88421 0 hayato 2013-05-30 07:00:26 +0000 A document tree and a shadow tree are used mutually exclusive in the spec. Can we define a term that can specify either a document tree or a shadow tree? In addition to that, can we define the relationship of trees using the terms of (child, parent, descendant or ascendent) rather than (nesting, enclosing)? Hopefully, that makes the spec simpler. For example, we can define an *inclusive-ancestor tree* and use that in the spec. WDYT? 88456 1 dglazkov 2013-05-30 16:34:50 +0000 (In reply to comment #0) > A document tree and a shadow tree are used mutually exclusive in the spec. > > Can we define a term that can specify either a document tree or a shadow > tree? A tree? http://dom.spec.whatwg.org/#concept-tree :) > > In addition to that, can we define the relationship of trees using the terms > of (child, parent, descendant or ascendent) rather than (nesting, enclosing)? What's wrong with nesting and enclosing? I am trying to understand the problem you're trying to solve. > Hopefully, that makes the spec simpler. For example, we can define an > *inclusive-ancestor tree* and use that in the spec. Where do we need it? 88499 2 hayato 2013-05-31 06:33:21 +0000 (In reply to comment #1) > (In reply to comment #0) > > A document tree and a shadow tree are used mutually exclusive in the spec. > > > > Can we define a term that can specify either a document tree or a shadow > > tree? > > A tree? http://dom.spec.whatwg.org/#concept-tree :) Agreed. We can use a tree. :) > > > > > In addition to that, can we define the relationship of trees using the terms > > of (child, parent, descendant or ascendent) rather than (nesting, enclosing)? > > What's wrong with nesting and enclosing? I am trying to understand the > problem you're trying to solve. > > > Hopefully, that makes the spec simpler. For example, we can define an > > *inclusive-ancestor tree* and use that in the spec. > > Where do we need it? I've come up this idea when I was writing these parts of Event.path. If TREE1 and TREE2 are the same, push NODE2 to RESULT Otherwise, if TREE1 is enclosed by TREE2, push NODE2 to RESULT If we had defined relationships between trees, we could rewrite that as: If TREE2 is an inclusing ancestor tree of TREE1, push NODE2 to RESULT Also I could rewrite related target resolution algorithm by using such terms. That would make the section 5, Event, more readable, I hope. Yet another motivation came from this bug: https://code.google.com/p/chromium/issues/detail?id=244779 tasak@ misunderstood the meaning of 'enclosing'. That made him implement wrongly. It could be nice if we could avoid such a confusion by using more familar terms. Also, we can replace 'a document tree and a shadow tree' with 'a tree and its child tree' in some parts of the spec. For example, > Since a node in a document tree and a node in a shadow tree never have the same root, there may never exist a valid DOM range that spans either both a document tree and a shadow tree, or multiple shadow trees. This sentence should not be applied only to relationship between 'a document tree' and 'a shadow tree'. That should be applied to 'tree and its child tree'. This is just rough my idea. I am not sure we can get much benefits from these terms. Let me think further... 88500 3 hayato 2013-05-31 06:46:00 +0000 I've changed the subject of this issue. 91202 4 hayato 2013-07-24 05:14:34 +0000 Fixed. The new spec introduced a tree of trees. https://dvcs.w3.org/hg/webcomponents/rev/dbf47f602628