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

<details><summary>Editing WG Nov 14, 2024 IRC notes: Resolved to go with option 1</summary>

08:05 <whsieh> https://github.com/w3c/selection-api/issues/2
08:05 <whsieh> Di: discussed at TPAC, we should have a new composed range concept in the spec. unclear how to track selection endpoints in different trees
08:06 <Di> https://github.com/dizhang168/shadow-dom-selection/blob/main/Selection%20API%20-%20composed%20range.pdf
08:06 <whsieh> Di: 1. want to define what a composed range is (defn. in slide above)
08:07 <whsieh> Di: could make it inherit from live range but that runs into other issues
08:07 <whsieh> Di: 2. define association between live range and selection
08:08 <whsieh> Di: (see above slides for more details on updates to getRangeAt and setBaseAndExtent)
08:09 <whsieh> johanneswilm: does this mean you always have live range in composed range? or only 1
08:10 <whsieh> Di: live range implies existence of composed range (?)
08:11 <whsieh> mfreed: both are implementable, yes?
08:11 <whsieh> Di: yes
08:15 <whsieh> mfreed: preference?
08:15 <whsieh> Di: option 1 might be more straightforward to implement
08:15 <whsieh> johanneswilm: impact on JS devs?
08:15 <whsieh> Di: in practice, JS developers shouldn't need to care
08:15 <whsieh> Di: more browser-internal. but it should be in the spec, since it's useful for defining other algorithms
08:15 <whsieh> johanneswilm: sounds like this is just an implementation detail
08:16 <whsieh> mfreed: also my comment earlier — seems like this can be implemented by a browser engine either way. this is essentially a way to rigorously define what happens when we say "composed range from the selection", etc.
08:16 <whsieh> Di: advantage is that this would allow us to define editing operations
08:17 <whsieh> dandclark: can you remind me of the current state of the spec?
08:17 <whsieh> Di: selection can have a range, range is anything that implements abstract range
08:17 <whsieh> Di: browsers implement live range
08:17 <whsieh> dandclark: gut reaction — easier to think about the version where there's the 1 range. we compute composed ranges on the fly
08:18 <masonf> +1 my vote is option 1
08:18 <whsieh> dandclark: probably easier to have the spec that way (maps to option 1)
08:18 <whsieh> whsieh: same
08:19 <whsieh> resolution: lets' go with option 1
08:20 <whsieh> (would be good to confirm with Sanket et al.)
</details>

where option 1 is:
Each selection can be associated with one composed range and each composed range can be associated with one range.
`Selection <-> Composed Range <-> Live Range`

and option 2 is:
Each selection can be associated with one composed range and one range.
Selection <-> Live Range
Selection <-> Composed Range

@annevk @sanketj @smaug---- for reference

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

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