On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren <m...@mozilla.com> wrote: > 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.
I don't think it's consistent at all. In one case, you're calling a Selection method. In the other case, you're calling a Range method. Range methods shouldn't behave differently based on whether the Range is attached to a Selection. You actually have no way of telling whether a given Range is part of a Selection, right? > 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. True. You can still use the Range methods, you just have to do .removeRange() and .addRange() to update it. So it's not a significant issue, I think.