Dom: `compareDocumentPosition` should allow comparison of elements in the same shadow-including root

[bicknellr]

(Some discussion on this already happened in #309.)

https://dom.spec.whatwg.org/#dom-node-comparedocumentposition

compareDocumentPosition should be able to compare nodes with different roots if those nodes have the same shadow-including root and the user indicates they would like to compare using the composed tree.

Consider:

<div>
  <!-- ShadowRoot -->
    <slot></slot>
    <div id="A"></div>
  <!-- /ShadowRoot -->
  <div id="B"></div>
</div>

which composes to something 'like':

<div>
  <!-- ShadowRoot -->
    <slot>
      <div id="B"></div>
    </slot>
    <div id="A"></div>
  <!-- /ShadowRoot -->
</div>

A.compareDocumentPosition(B, {composed: true});, or something similar, should return DOCUMENT_POSITION_PRECEDING.

A strange situation this brings up is how fallback content of a slot compare to other nodes in the same shadow-including root when that slot has assigned nodes. IMHO, when comparing using the composed tree, the slot's fallback content should be considered disconnected.

Also, given that a ShadowRoot doesn't have a natural position in its host's tree (or relative to its host's descendants - it's not a special child) without composition, I think step 6 in the specced behavior should continue to apply if no explicit opt-in is indicated.

[travisleithead]

Do you find that you need to compare nodes across Shadow DOM very often? And if so, why? If this is a current problem, I suppose you have written some extra logic to implement a shadow-including comparison utility function?

[annevk]

Thanks, given the lack of interest thus far and lack of popular library that does this, I'm going to close this. If this does ever become something that's needed we can obviously reconsider.

[MKhowaja]

Running into this issue as well.
Implemented a workaround in the meantime here:
https://stackblitz.com/edit/comparedocumentposition-shadowroot-patch