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

On 01/24/2015 09:52 AM, Koji Ishii wrote:
> On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren <mats@mozilla.com> wrote:
>>
>>> 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.
>
> We could add, say, getRangeProxyAt(index) to get a selection object
> that has Rage interface if this is really what authors want.
>
> But right now, authors are not relying on the live-ness behavior
> because it's not interoperable. As I understand, "not-interoperable"
> is bigger issue than "getRangeAt(index) does not have live-ness".
Right now the liveness doesn't really cause issues, since only some UAs support it.
But that doesn't mean getRangeAt should return cloned ranges.
Adding another getRange*At would just pollute the API.

The more I think this, the more I'm leaning over to the option that we should play with
live range objects with selection.
(but perhaps there is some different kind of API model which
can support multiple ranges and getRangeAt could be left as a legacy method and return clones.
But adding something like getRangeProxyAt would not be such new model.)


> In
> selections and editing, we have so much we wish to do, I'd like us to
> solve bigger issues first,
Like what?

How we end up supporting multiple ranges is rather big thing and something
to keep in mind even if we end up having some kind of v1 spec without
support for it.


-Olli


> make them available to editor developers,
> then improve as needed.

>
> Actually -- well, only if you're interested in doing this -- you could
> have both methods, then see how much authors prefer the live-ness. If
> it's proved that the live-ness is so much liked by editor developers,
> and if we have solved other critical issues at that point, I do not
> see any reasons other browsers do not follow.
>
> /koji
>

Received on Saturday, 24 January 2015 12:53:19 UTC