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: Wed, 21 Jan 2015 15:20:09 +0000
Message-ID: <54BFC3A9.2070901@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/17/2015 05:11 PM, Aryeh Gregor wrote:
> On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren <mats@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
Received on Wednesday, 21 January 2015 15:20:40 UTC

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