Open rniwa opened 11 months ago
I think this is essentially what I mentioned in https://github.com/w3c/selection-api/issues/161#issue-1503058584 which references https://github.com/WICG/webcomponents/issues/79#issuecomment-972726532.
Let's think about this a bit:
Selection
. Currently Selection
is mostly defined in terms of a single range, but this might change and it makes sense to let Selection
be responsible for rendering the range when it changes and such.
getRange(0)
and manipulates that, this selection live range needs to be updated as well (or perhaps thrown away). We need to be careful not to introduce loops there.@mfreed7 @rniwa @smaug---- thoughts?
Similar to my reply on #79, I agree.
Your summary above sounds exactly right to me. The devil is in the details, but the broad strokes look correct.
What might be tricky is that if someone accesses getRange(0) and manipulates that, this selection live range needs to be updated as well (or perhaps thrown away). We need to be careful not to introduce loops there.
Seems like that operation (manipulation of a live range) should go through the same "update selection" algorithm which should take care of the details.
Seems like that operation (manipulation of a live range) should go through the same "update selection" algorithm which should take care of the details.
That would mean we have multiple ranges associated with the selection representing the same conceptual range within the selection.
Maybe instead the "public selection live range" (getRange(0)
) should point directly to the selection live range and update that, which then updates the selection. With multiple ranges that would still work, with each selection live range having its own public selection live range.
The most difficult part here is probably defining the "selection live range".
This needs to be updated correctly by the various node tree mutation algorithms.
That is the tricky bit. Not only we need to handle mutations in one tree but I believe also changes to slotting should affect selection.
I wrote a test to check the behavior of a selection range which is in a shadow DOM and after the host is removed. Currently, Chrome keeps the range as a selection range without modifying the range in the shadow. Firefox removes the range from Selection
without updating the range. (It seems that Safari collapse the selection range to the removed node position, but the test fails at checking the stored range behavior.)
I changed the Firefox's behavior as so for consistency with https://github.com/whatwg/dom/issues/1274 and https://github.com/w3c/selection-api/issues/175, but could be reasonable to make the selection range cloned (to avoid unexpected range update for the referrers of the Range
object) and collapsed to the parent DOM tree (like as in the light DOM, i.e., like Safari).
We should specify the behavior when DOM trees are mutated (e.g. shadow host is removed) when selection cross shadow boundaries.