Re: [w3c/selection-api] Clarify association between a selection and its range (#2)

I see. My original proposal was to avoid having to modify Range and have everything selection scoped within the Selection. I have given it more thoughts and I am good with using a composed live range instead of introducing a new composed selection concept. The user facing changes will be the same and the implementation can be left to the user agent. Bonus, the specification should be easier because we utilize the existing Range (live range) definitions.

To simplify, the structure would be:
* `Selection <-> Composed live range`

From a standard point of view, the main changes needed would be:
### In DOM spec
* Define composed before, composed after, composed equal
* Define a Range is "composed" if it is associated with a [selection](https://w3c.github.io/selection-api/#dfn-selection) and its shadow-including root is the document.
* Modify the range's “set the start or end of a range” algorithm to not collapse if it is a composed range and we should compare with shadow-inclusive roots instead (maybe)

### In the Selection spec
* Change to "Each selection can be associated with a single composed live range."

Note:
We don’t need to redefine how the composed live range is rescoped at getRangeAt(0) because we are returning the reference to the range as it is.
We don’t need to redefine anchorNode/focusNode/anchorOffset/focusOffset because the definition already says we should return null if anchor/focus is not in the document tree (i.e. in a shadow tree instead).

Also, I don't think we need to update the mutation related spec. For example, let's say we have a composed live range and it has a start node inside a shadow tree. That shadow tree's host is removed. The spec [says](https://dom.spec.whatwg.org/#concept-node-remove) to rescope this start node to the host's parent. That is the right step to follow. I have added a few [WPT tests](https://github.com/web-platform-tests/wpt/blob/master/selection/shadow-dom/tentative/Selection-getComposedRanges-dom-mutations-removal.html) of what's expected if we keep the mutation rules we have now. Please correct me if that is the wrong assumption.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/2#issuecomment-2469410295
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/selection-api/issues/2/2469410295@github.com>