Change Selection to be associated with a composed live range #345
Conversation
| <var>end</var>, run these steps: | ||
| </p> | ||
| <ol> | ||
| <li>Let <var>newCachedRange</var> be a new {{Range}} object.</li> |
There was a problem hiding this comment.
Here, the {{Range}} should refer to the Range interface defined in [dom]. However, it keeps pointing to range, which I redefined in this PR. How can I overwrite this behavior?
There was a problem hiding this comment.
I think I would just remove the dfn of range that you introduced here. We already know the type of "composed live range", once it's able to link to DOM.
|
(I know this is a WIP, just note that the cached live range should be interpreted as legacy selection range) |
| <var>newFocus</var>. | ||
| <li>If <var>node</var>'s [=tree/root=] is not the same as | ||
| [=this=]'s <a>range</a>'s [=tree/root=], <a>reset the range</a> with | ||
| <var>newFocus</var> and <var>newFocus</var>. | ||
| </li> | ||
| <li>Otherwise, if <var>oldAnchor</var> is [=boundary point/before=] |
There was a problem hiding this comment.
I'm curious about this. It looks like DOM's position computing algorithm that determines "before" and "after" expects that the two input nodes always have the same root, which might not be true, since after all DOM's "set the start or end" algorithm has cross-root handling logic that we add on to in whatwg/dom#1342.
I guess we should either change "set the start or end" to accept cross-root nodes, or catch that case early on here, and skip the before/after comparison checks.
There was a problem hiding this comment.
I prefer option 2, "catch that case early on here, and skip the before/after comparison checks."
We will need to update the setBaseAndExtent and extend() functions to check that the boundary points are within the same root before we call "before/after" to "set the start/end". I can think of two easy way to achieve that:
- If anchor and focus has the same root and anchor is before focus, set range's start to anchor and range's end to focus.
- Otherwise, set range's start to focus and range's end to anchor.
OR
- If anchor and focus has different roots:
4.1 If anchor is in a shadow tree, set anchor to its shadow host.
4.2 If focus is in a shadow tree, set focus to its shadow host. - If anchor is before focus, set range's start to anchor and range's end to focus.
- Otherwise, set range's start to focus and range's end to anchor.
| <li>[=Range/Set the start=] of <var>newCachedRange</var> to <var>start</var>. | ||
| </li> | ||
| <li>[=Range/Set the end=] of <var>newCachedRange</var> to <var>end</var>.</li> | ||
| <li>Let <var>newRange</var> be a new <a href="TODO">composed live range</a> |
There was a problem hiding this comment.
We should add a note in this step to indicate that while this looks identical to the above steps, newCachedRange and composed selection range could actually end up in very different states, because when we update newCachedRange we go through the "set the start|end" algorithms which collapse in the cross-root case, while for composed selection range we just manually set the members without any algorithm collapsing or anything.
Note: This PR is not ready to merge, but can 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:
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. However, for getComposedRanges(), we will refer to the composed live range's endpoints directly. This includes updating definitions for anchor/focus, getRangeAt(0), addRange(), removeRange(), etc.
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:
For browsers that are shipping the feature, implementation bugs are filed for the proposed changes (link to bug, or write "Not Implementing"):
Preview | Diff