W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

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

From: Aryeh Gregor <ayg@aryeh.name>
Date: Sun, 25 Jan 2015 14:02:29 +0200
Message-ID: <CAKA+AxkbmS_6_-p-FxXuCAjczsXZ5bpqbmz-peC9r3C8G=rqnw@mail.gmail.com>
To: Mats Palmgren <mats@mozilla.com>
Cc: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
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 Sunday, 25 January 2015 12:03:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC