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

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 12:41:25 UTC