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: Sat, 24 Jan 2015 19:55:33 +0200
Message-ID: <CAKA+AxnmL+LCqevjrCbvZPaH5rm3w=-yxwL+XCJYTTPxRJKPXQ@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>
Cc: Olli Pettay <olli@pettay.fi>, Mats Palmgren <mats@mozilla.com>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Sat, Jan 24, 2015 at 3:28 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> Looks like we're in consensus that a) it doesn't really cause issues
> today, and b) there are scenarios where live-ness is nice.

I don't agree that it doesn't cause issues now.  Unless we want Range
methods to behave differently based on whether they're in a Selection,
returning a live range means you can't restrict what nodes are in the
selection, e.g., detached nodes.  This has caused at least one bug in
Gecko.  It would be much easier for IE/Gecko to switch to returning
copies than for WebKit/Blink to switch to returning live ranges.  And
this opens up the possibility of normalizing the selection in a way
that makes writing code to handle selections significantly easier,
e.g., limiting the types of nodes that the selection can be in.  So I
think it makes more sense to spec returning a copy.

I don't have any opinion on how this should be prioritized relative to
other editing work.  I will note that it would be quite easy for Gecko
to switch to returning a copy, so it doesn't have to take significant
implementation work away from other projects.
Received on Saturday, 24 January 2015 17:56:22 UTC

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