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: Sat, 10 Jan 2015 02:18:22 +0900
Message-ID: <CAN9ydbXNoXafbcc6eUh8F9WOmu3MDd0FO9x8yuUSuBs63fyiZw@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>
Thank you Aryeh for the explanation to this newbie, I understand that
better now. That was a bit different from what I had in mind, but glad
to see you agree to return a value.

So, sounds like we're in consensus to change it to return a value?


On Fri, Jan 9, 2015 at 9:40 PM, Aryeh Gregor <ayg@aryeh.name> wrote:
> On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 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?
> The advantage of the IE/Gecko behavior is you can alter the selection
> using Range methods.  The advantage of the WebKit/Blink behavior is
> you can restrict the ranges in the selection in some sane fashion,
> e.g., not letting them be in detached nodes.  WebKit/Blink cannot
> change to return a reference unless they allow arbitrary ranges in
> selections, which last I checked they don't, and I'm guessing they
> would have trouble supporting it.  Whereas IE/Gecko could easily
> change, and authors who already supported WebKit/Blink wouldn't lose
> any features.  So I guess returning a value makes the most sense.
> (If you return a reference, you must allow arbitrary ranges, because
> the author could call setStart() on the returned range with any value
> you want, and they will expect that the range's new start will be
> exactly what they set it to.)
> On Wed, Jan 7, 2015 at 12:08 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>> I also guess that we need to ask more work to the spec editor to
>> support the liveness, such as:
> My old spec had no trouble answering these questions.  I don't think
> it's particularly complicated, except it requires allowing arbitrary
> ranges to be in selections, and I suspect WebKit/Blink would have
> trouble dealing with that.
>> - What will happen to the live-object on removeAllRanges()?
> The range is detached from the selection, so further changes have no effect.
>> - Would the live-object keeps the same reference for removeAllRanges()
>> + addRanges()?
> No.  If you use addRange(), a reference to your existing range is put
> in the selection.
>> - It may never happen, but when multiple ranges are supported, are
>> they bound to index?
> Everyone wants to kill this feature, so it's moot.
>> Specing them in detail and writing tests for all these cases would be
>> quite a bit of work.
> I already wrote the spec and the tests, although I'm sure there are
> still some gaps.  I think WebKit/Blink are the bigger obstacle.
Received on Friday, 9 January 2015 17:18:49 UTC

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