W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

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

From: Aryeh Gregor <ayg@aryeh.name>
Date: Sat, 24 Jan 2015 19:50:54 +0200
Message-ID: <CAKA+Axmp9Zr=h2sppH3hxG3JOD+hKt_BU4xo4C3k=76fzvhqsA@mail.gmail.com>
To: Mats Palmgren <mats@mozilla.com>
Cc: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC