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 21693 - [Shadow]: clarify compareDocumentPosition for elements in different shadow trees
Summary: [Shadow]: clarify compareDocumentPosition for elements in different shadow trees
Status: RESOLVED INVALID
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 14978
  Show dependency treegraph
 
Reported: 2013-04-15 06:38 UTC by Takashi Sakamoto
Modified: 2013-04-30 22:13 UTC (History)
1 user (show)

See Also:


Attachments

Description Takashi Sakamoto 2013-04-15 06:38:40 UTC
I would like to confirm two things:

(1) whether we use DOCUMENT_POSITION_DISCONNECTED when comparing elements in different shadow trees whose document root is the same or not

    If document roots of different shadow trees are different, we should use DOCUMENT_POSITION_DISCONNECTED.

(2) whether we use the followings instead of DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC when comparing elements in different shadow trees:
DOCUMENT_POSITION_PRECEDING	2
DOCUMENT_POSITION_FOLLOWING	4
DOCUMENT_POSITION_CONTAINS	8
DOCUMENT_POSITION_CONTAINED_BY	16

    (2) will make it easier to solve styles in different shadow trees, i.e. multiple and nested shadow trees.


For example,
----
var a = document.createElement('div');
var b = document.createElement('div');
var c = document.createElement('div');

// #document
//   <div id=a>
//   <div id=b>
//      #shadow-root
//         <div id=c>

document.body.appendChild(a);
document.body.appendChild(b);
b.createShadowRoot().appendChild(c);
----

Currently a.compareDocumentPosition(c) returns DOCUMENT_POSITION_DISCONNECTED | DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC

So, which a.compareDocumentPosition(c) should return?

(a) DOCUMENT_POSITION_FOLLOWINGS or
(b) DOCUMENT_POSITION_FOLLOWINGS | DOCUMENT_POSITION_DISCONNECTED or
(c) DOCUMENT_POSITION_DISCONNECTED | DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC
Comment 1 Dimitri Glazkov 2013-04-16 18:28:52 UTC
My first reaction is that it should return DOCUMENT_POSITION_DISCONNECTED, since document tree and shadow tree are two disconnected trees. Can you explain why it may be good to do something different?
Comment 2 Takashi Sakamoto 2013-04-17 03:44:10 UTC
Sure. I will explain what I want.

So currently Blink does:

(1) all style elements are sorted in document order by using compareDocumentPosition.
(2) rules are picked up in (1)'s order and inserted into StyleResolver.

And I'm planning to implement a scoped style tree.

So if I can always rely on the above (1) and (2) (including style elements in shadow dom trees), when creating a new node and inserting the node into a scoped style tree, I can also assume that all parent nodes have been inserted into the tree. This assumption would make code simpler.

So is it ok to use DOCUMENT_POSITION_FOLLOWINGS | DOCUMENT_POSITION_DISCONNECTED for a.compareDocumentPosition(c)?
Comment 3 Olli Pettay 2013-04-17 10:06:47 UTC
Takashi, that sounds like an implementation detail, not something that need
to be exposed to web.
Comment 4 Dimitri Glazkov 2013-04-17 17:12:19 UTC
(In reply to comment #3)
> Takashi, that sounds like an implementation detail, not something that need
> to be exposed to web.

FWIW, I agree.

Just to play devil's advocate against my own opinion: one could see the disparity of what internal API says vs. what external API reports as undesirable, since it creates more magic in the platform.
Comment 5 Takashi Sakamoto 2013-04-18 00:25:00 UTC
Thank you.

I see.
I will implement an internal API.