This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22203 - [Shadow]: Define relationships between trees using terms of {child, parent, descendant, ancestor}.
Summary: [Shadow]: Define relationships between trees using terms of {child, parent, d...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 22716
  Show dependency treegraph
 
Reported: 2013-05-30 07:00 UTC by Hayato Ito
Modified: 2013-07-24 05:14 UTC (History)
0 users

See Also:


Attachments

Description Hayato Ito 2013-05-30 07:00:26 UTC
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?
Comment 1 Dimitri Glazkov 2013-05-30 16:34:50 UTC
(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?
Comment 2 Hayato Ito 2013-05-31 06:33:21 UTC
(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...
Comment 3 Hayato Ito 2013-05-31 06:46:00 UTC
I've changed the subject of this issue.
Comment 4 Hayato Ito 2013-07-24 05:14:34 UTC
Fixed. The new spec introduced a tree of trees.
https://dvcs.w3.org/hg/webcomponents/rev/dbf47f602628