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: Koji Ishii <kojiishi@gmail.com>
Date: Sat, 24 Jan 2015 16:52:44 +0900
Message-ID: <CAN9ydbUjTNYrwq3AtdnY=XXtjt=ubZq0TYdK2YhHm0N6q571Tg@mail.gmail.com>
To: Mats Palmgren <mats@mozilla.com>
Cc: Aryeh Gregor <ayg@aryeh.name>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
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". In
selections and editing, we have so much we wish to do, I'd like us to
solve bigger issues first, 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.

Received on Saturday, 24 January 2015 07:53:16 UTC

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