Change Selection to be associated with a composed live range

[dizhang168]

The goal of this PR is to add the definitions necessary so the getComposedRanges() API can access a composed live range's endpoints that might cross shadow boundaries instead of accessing the legacy uncomposed live range, which is scoped to be contained within one root only.

This specification is aligned with the currently shipped getComposedRanges() in Webkit and Gecko (behind a flag). It only adds definitions and references; it does not change the structure of any existing user-facing API.

Note: This PR is not ready to merge, but can be reviewed. It depends on the definitions "composed live range" and "cached live range", being specced at: whatwg/dom#1342
The Editing WG issue discussing this change is: #2

To summarize, this spec PR changes:

1. Each selection can be associated with a single composed live range.
   Most of the existing Selection API functions will refer to the composed live range's cached live range to make sure we are backward compatible. This includes updating definitions for anchor/focus, getRangeAt(0), addRange(), removeRange(), etc. However, for getComposedRanges(), we will refer to the composed live range's endpoints directly.

2. Add "reset the range" algorithm
   We add a new "reset the range" of this selection algorithm, which is called by collapse(), collapseToStart(), collapseToEnd(), extend(), setBaseAndExtent(), selectAllChildren(). This will make sure to create and set the composed live range and its cached live range, and call {{Range}}'s "set the start/end" algorithm.

For normative changes, the following tasks have been completed:

• Editing WG resolution on the proposed changes, with at least two implementers participating and not objecting:

  • WebKit: Positive (Selection API: getComposedRanges mozilla/standards-positions#1055)
  • Chromium: Positive
  • Gecko: Positive (Selection API: getComposedRanges WebKit/standards-positions#376)

• For browsers that are shipping the feature, implementation bugs are filed for the proposed changes (link to bug, or write "Not Implementing"):

  • WebKit (https://bugs.webkit.org/show_bug.cgi?id=216325)
  • Chromium (https://issues.chromium.org/issues/40286116)
  • Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1430308)

---

Preview | Diff

[sefeng211]

(I know this is a WIP, just note that the cached live range should be interpreted as legacy selection range)

[dizhang168]

Hi @rniwa, could you help review? This PR uses the "composed selection range" getting defined in DOM. Thank you.

[rniwa]

The change looks good!

[dizhang168]

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 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.

[smaug----]

Overall the changes look great.
Stringifier behavior of Selection would need to be clarified though, especially if one uses slots to reorder nodes visually.