Re: [Selection] Should selection.getRangeAt return a clone or a reference?

On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren <mats@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.

Received on Saturday, 24 January 2015 17:51:48 UTC