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

Thanks for the explanation, very helpful. Here is my thought process.

Right now, the spec says we have:
* `Selection` <-> `Range (live range)`.

If we introduce the concept of a live composed range, then the mapping would be:
* `Selection` <-> `Composed Range (live range)` <-> `Range (live range)`
* For setBaseAndExtent(), it updates this composed range.
* We will need to revisit mutations.
* For getRangeAt(0), we will get the live composed range and rescope it. This live range will be pointing to the live composed range and its mutation will affect it.
* For getComposedRanges(), we can get the start/end boundary points of live composed range.

What I am proposing instead is to not add/change Range definitions: ranges are not composed. Instead, we add a new concept of a **Composed Selection**. The composed selection internally stores anchor and focus endpoints to be across the document. It has no direct pointer to any range.
* `Selection` <-> `Composed Selection`
* `Selection` <-> `Range (live range)`
* For setBaseAndExtent(), it updates both the Composed Selection and the Live Range. Live range might collapse if across trees, but there are no such check on composed selection.
* When mutations happen to a live range, it will call UpdateSelection(), which will UpdateComposedSelection().
* For getRangeAt(0), no change needed.
* For getComposedRanges, we can get the start/end by accessing the composed selection's anchor/focus.

I think this approach might be easier on the specifications, while still giving the user agents enough leeway on how they want to implement it.

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

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