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

Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

From: Aryeh Gregor <ayg@aryeh.name>
Date: Wed, 28 Jan 2015 13:35:09 +0200
Message-ID: <CAKA+Axm+kk8R1S+BGWida0TyxJQw31-MTtE55DO5Znh5-uUm2A@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Olivier Forget <teleclimber@gmail.com>, Ben Peters <Ben.Peters@microsoft.com>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Tue, Jan 27, 2015 at 4:31 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> It's true that you could use multi-range selections to select in
> visual order. But there are bunch of operations defined against
> selections. What does it copy? What will happen when you type "a" to
> replace the selected text? Spell check? Bi-di algorithm? Almost every
> text algorithm is built on top of the model, which is the DOM today,
> we can't just replace it.

In all of these cases, typically, the most correct thing you can do is
do the operation on each range separately in sequence, probably in DOM
order for lack of a better option.  Copy should concatenate the
selected ranges into the clipboard.  Replacement probably would delete
all the ranges and replace the first one.  I don't see what spellcheck
or bidi have to do with selections at all.  All this is certainly not
simple to work out, and in some cases there will be no good answer for
what to do, but it's something you have to do if you want to deal with
non-contiguous selections.

> I think visual order selections, if ever happens, should have a
> different architecture, and it should not be handled together with
> multi-range selections.

What do you mean by "visual-order selections," and can you give a
specific example of something that should behave differently for
visual-order and multi-range selections?
Received on Wednesday, 28 January 2015 11:42:55 UTC

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