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: Koji Ishii <kojiishi@gmail.com>
Date: Wed, 7 Jan 2015 19:08:42 +0900
Message-ID: <CAN9ydbXP=ka7XG9B1W1daFjmwB0KGEa9w=WfCc7=P=-jBmBytQ@mail.gmail.com>
To: Tim Down <tim@timdown.co.uk>
Cc: Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>
While I agree that it's nice, I have mild preference to return a
clone. As Olii said, changing from clone to live would involve quite a
bit of code. I feel sorry for already implemented people though.

I also guess that we need to ask more work to the spec editor to
support the liveness, such as:
- What will happen to the live-object on removeAllRanges()?
- Would the live-object keeps the same reference for removeAllRanges()
+ addRanges()?
- It may never happen, but when multiple ranges are supported, are
they bound to index?
Specing them in detail and writing tests for all these cases would be
quite a bit of work.

/koji

On Wed, Jan 7, 2015 at 9:02 AM, Tim Down <tim@timdown.co.uk> wrote:
> For what it's worth as a user of the range and selection APIs, updating a
> live range is convenient and preferable, but since this has never worked in
> all browsers, I never do it and have never recommended it to anyone else.
> Therefore if Gecko changes, nothing really changes for me, so I don't care.
> Knock yourself out, Mozilla.
>
> Tim
>
> On 6 January 2015 at 22:32, Ryosuke Niwa <rniwa@apple.com> wrote:
>>
>> https://github.com/w3c/selection-api/issues/40
>>
>> Trident (since IE10) and Gecko both return a live Range, which can be
>> modified to update selection.  WebKit and Blink both return a clone Range so
>> that any changes to the Range doesn't update the selection.
>>
>> It appears that there is a moderate interest at Mozilla to change Gecko's
>> behavior.  Does anyone have a strong opinion about this?
>>
>> - R. Niwa
>>
>>
>
Received on Wednesday, 7 January 2015 10:09:14 UTC

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