Bug 103599 - Node::compareDocumentPosition should return either FOLLOWING OR PRECEDING for nodes which are not in the same tree.
Summary: Node::compareDocumentPosition should return either FOLLOWING OR PRECEDING for...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Takashi Sakamoto
URL:
Keywords:
: 103600 (view as bug list)
Depends on:
Blocks: 72352
  Show dependency treegraph
 
Reported: 2012-11-28 21:15 PST by Hayato Ito
Modified: 2013-01-06 20:15 PST (History)
4 users (show)

See Also:


Attachments
WIP (10.66 KB, patch)
2012-12-05 20:54 PST, Takashi Sakamoto
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hayato Ito 2012-11-28 21:15:27 PST
According to the spec (http://dom.spec.whatwg.org/#dom-node-document_position_disconnected): 

> If other and reference are not in the same tree, return the result of adding DOCUMENT_POSITION_DISCONNECTED, DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC, and either DOCUMENT_POSITION_PRECEDING or DOCUMENT_POSITION_FOLLOWING, with the constraint that this is to be consistent, together and terminate these steps.

> Whether to return DOCUMENT_POSITION_PRECEDING or DOCUMENT_POSITION_FOLLOWING is typically implemented via pointer comparison. In JavaScript implementations Math.random() can be used.


We should return the value which has either DOCUMENT_POSITION_PRECEDING or DOCUMENT_POSITION_FOLLOWING flag with the constraint to be consistent.

Since Node.compareDocumentPosition is a web facing API, we should be careful about whether it's okay to add flag to the return value.
If users checks the return value using bitwise operation (e.g if ((return value & Node.DOCUMENT_POSITION_DISCONNECTED) != 0)), it's okay. But I am afraid most users don't do that.


I am adding tasak@ to cc since he needs a kind of total order for nodes in the different shadow tree.
Comment 1 Hayato Ito 2012-11-28 23:47:48 PST
*** Bug 103600 has been marked as a duplicate of this bug. ***
Comment 2 Takashi Sakamoto 2012-12-05 20:54:23 PST
Created attachment 177919 [details]
WIP
Comment 3 Takashi Sakamoto 2012-12-10 01:45:05 PST
Shadow DOM spec was updated. It says:
----
For the purposes of the cascade order, the CSS rules for shadow trees that have the apply-author-styles flag set must be treated as scoped selectors with shadow root as their scope. In this context, for shadow trees A and B, the A's shadow root is treated as descendant of B's shadow root if A is enclosed by B.
----
c.f. http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#styles

and
----
Scope
If a declaration belongs to a ruleset with a scoped selector, the element it is scoped to can affect the cascade. For the purpose of this step, declarations from style attributes [CSSSTYLEATTR] are considered to be scoped to the element with the attribute, and all other declarations are considered to be scoped to the root element.
If the scoping elements of two declarations have an ancestor/descendant relationship, the declaration whose scoping element is the descendant wins. If one declaration is from a style attribute on an element and the other is from a ruleset scoped to that element, the declaration in the style attribute wins.
----

So we don't need to compare style elements in different tree scopes by using "document position", because an inner one, i.e. the declaration whose scoping element is the descendant, wins.