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 <a...@aryeh.name> wrote: > On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren <m...@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.