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

So...we discussed 31 e-mails, time to try to reach a consensus? Please
keep in mind, it's too obvious to everyone but you don't have to agree
to build a consensus. We can build a consensus if all can live with
single conclusion.

3 proposals so far:

Proposal A: Leave it undefined. If it's not causing interop issues, we
can leave it.
Proposal B: Clone.
Proposal C: Live.

Which one you *can't* live with, and which one do you prefer?

I can live with any, but prefer A or B.

If anyone has more to say, I didn't intend to interrupt, please add more info.

/koji

On Sun, Jan 25, 2015 at 9:02 PM, Aryeh Gregor <ayg@aryeh.name> wrote:
> On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren <mats@mozilla.com> wrote:
>> Gecko knows if a Range is part of a Selection or not.
>
> Authors don't, I don't think.  Of course, we could expose this info to
> authors if we wanted, so that's not a big problem.
>
>> True, I'm just saying that I don't see any practical problems in
>> implementing live ranges to manipulate the Selection if we want to.
>
> I don't think there are any implementation problems, I just think it's
> an API that's confusing to authors relative to the alternative
> (returning copies).  And it's probably easier for the UAs that return
> references to switch to returning copies than the reverse, so it
> increases the chance of convergence in the near term.  Also, if
> mutating the range throws, it will break author code; but if it fails
> silently, it creates a "what on earth is going wrong?!" head-banging
> scenario for authors.  And anything authors can do with a reference,
> they can do with a copy just as well, by mutating the copy,
> .removeRange(), .addRange().  So I think returning a copy makes much
> more sense.

Received on Tuesday, 27 January 2015 14:49:44 UTC