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: Mats Palmgren <mats@mozilla.com>
Date: Sat, 24 Jan 2015 23:31:02 +0000
Message-ID: <54C42B36.7040707@mozilla.com>
To: Aryeh Gregor <ayg@aryeh.name>
CC: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On 01/24/2015 05:50 PM, Aryeh Gregor wrote:
> 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?

Gecko knows if a Range is part of a Selection or not.
It's pretty much a one-line change to reject detached nodes if we want.

 > 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.

True, I'm just saying that I don't see any practical problems in
implementing live ranges to manipulate the Selection if we want to.

Received on Saturday, 24 January 2015 23:31:33 UTC

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