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

I just said it in the other thread, but just to clarify in this thread
too: I think non-contiguous selections are a great feature.  I think
exposing them to authors as multiple Ranges in a Selection has proven
to be not a good way to do it, because authors basically without
exception just ignore any ranges beyond the first.  When writing the
Selection code, I reviewed a decent amount of author code, and all of
it (I don't think I found an exception) just did .getRangeAt(0) and
ignored the rest.  Gecko has found that they misused the code
internally as well, as Ehsan demonstrated to me once.  If we want
non-contiguous selections to work in author code that's not specially
written to accommodate them, we should think of a different API,
perhaps the one I suggested in the other thread.

Also, to clarify, my initial selection spec accommodated multiple
ranges.  I deliberately removed support when it looked like no one
wanted to support the feature:
<https://dvcs.w3.org/hg/editing/rev/b1598801692d>.  Speccing it is not
the problem.  The bug was here, where I say that Ehsan and Ryosuke
agreed with it (at a face-to-face meeting we had at Mozilla Toronto):
<http://www.w3.org/Bugs/Public/show_bug.cgi?id=13975>

On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren <mats@mozilla.com> wrote:
> On 01/09/2015 12:40 PM, Aryeh Gregor wrote:
>>
>> 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.
>
> 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?

What are the reasons to return a clone anyway?  Is it important to be
able to call (mutating) Range methods on a Selection?  If we really
want authors to have convenience methods like setStartBefore() on
Selection, we could add them to Selection.

Received on Saturday, 17 January 2015 17:11:58 UTC