- From: Di Zhang <notifications@github.com>
- Date: Wed, 12 Mar 2025 15:45:02 -0700
- To: w3c/selection-api <selection-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 12 March 2025 22:45:06 UTC
dizhang168 left a comment (w3c/selection-api#345) > I wonder if the term "legacy selection range" makes sense. I gather we are not trying to deprecate these types of ranges. In the future, if we end up with even more range systems, we may end up with a large number of different "legacy" ranges that are still in use. But that's just wording. Good question, we are actually [discussing about the naming](https://github.com/whatwg/dom/issues/1363#issuecomment-2718305565) and currently landed on "legacy uncomposed range". Not the most intuitive I guess, but as you say, it is just wording.. > From the JS/author side of things, it would be of interest what is changing on the client side. There is no new API/method as far as I can tell. So what will the difference be? That ranges can now go across shadow root boundaries? Will this work with the existing getRange() method? Currently, there are no changes to the getRangeAt() method nor new API being introduced. It is all semantics so the output of getComposedRanges() can now cross shadow root boundaries interoperability, without breaking any spec rules. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/selection-api/pull/345#issuecomment-2719288094 You are receiving this because you are subscribed to this thread. Message ID: <w3c/selection-api/pull/345/c2719288094@github.com>
Received on Wednesday, 12 March 2025 22:45:06 UTC