Change Selection to be associated with a composed live range #345
Conversation
|
(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.
There was a problem hiding this comment.
Which option did you opt for? It's not clear given the discussion here. Plus, I don't think we can just grab the shadow host of each anchor and focus and expect both hosts to be in the same root... what about nested shadow roots?
There was a problem hiding this comment.
I went with the first option and updated the steps for setBaseAndExtent to:
If anchorNode's root is the same as focusNode's root and anchor is before focus, set the composed selection range with anchor and focus. Otherwise, set the composed selection range with focus and anchor.
This is not grabbing the shadow host and only compares the roots. This also means that for shadow tree cases, the range is set using focus as start and anchor as end. That might feel a little unintuitive, but it should be correct because:
- For live ranges, this will get collapsed to end (since we first call setStart, then setEnd).
- For composed selection range, we determinate the anchor/focus based on the direction.
|
Hi @rniwa, could you help review? This PR uses the "composed selection range" getting defined in DOM. Thank you. |
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