Re: [whatwg/dom] Should a Range object be able to update a Selection object (#772)

Do we have reasonable test coverage to ensure that mutation of the live range through the API updates the selection without shadow trees? And is that interoperable? (I suspect it is, but it would be good to confirm that is indeed our baseline.)

Now, when you manipulate the live range I think we have to manipulate the selection (and therefore the live composed range) as well, as otherwise you could detect the presence of a shadow root. There might be some ways to do that anyway, but in general I think it's a good rule of thumb to try and avoid doing that and let decisions flow from that principle.

However, this presents an interesting case. While the live range now knows about a shadow tree, does that mean that `window.getSelection()` should too? I guess that's okay as telling this particular range about a shadow tree essentially destroys its encapsulation due to `getRangeAt()`. So `Selection` APIs can probably stay in sync with `getRangeAt()` in that respect and sometimes reveal shadow trees if the live range does so too.

But what does that mean for the live composed range? C seems weird. The API says the selection is bigger than it is presented to the end user with no benefit to encapsulation. B seems reasonable, though I wonder what the `Selection` API returns? The same as `getRangeAt()`? A also seems reasonable. After all, if you wanted to update the selection you really shouldn't be using the `Range` object to do so.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/772#issuecomment-2498158745
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/772/2498158745@github.com>