On 01/17/2015 05:11 PM, Aryeh Gregor wrote:
On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren <m...@mozilla.com>
wrote:
It would be easy to change Gecko to ignore addRange() calls if the
range start/end node is detached. We could easily do the same for
range.setStart*/setEnd* for ranges that are in the Selection. Would
that address your concern about detached nodes?
I think so, yes, but it would mean making Range methods behave
differently depending on whether the range is in a selection. Is that
really sane?
It seems fine to me. WebKit/Blink already rejects(*) a range with
detached nodes in the addRange call. Imposing the same restriction on
a (live) Selection range is consistent with that.
(*) It appears to collapse the current range, if any, at the end point,
but I might be mistaken on the exact behavior. I would prefer to simply
ignore calls with detached nodes and leave the Selection as is, but I
don't feel strongly about it.
If we really want authors to have convenience methods like
setStartBefore() on Selection, we could add them to Selection.
Selection methods wouldn't provide the same functionality though.
Selection.setStart* would presumably be equivalent to setStart*
on the first range in the Selection, but how do you modify the start
boundary point on other ranges when there are more than one?
I guess we could add them as convenience methods, making setStart*
operate on the first range and setEnd* on the last, but it's still
an incomplete API for multi-range Selections.
/Mats
