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: Sun, 25 Jan 2015 13:57:51 +0200
Message-ID: <CAKA+AxmgX+EH7JK+w=E7vbVY27NeG-3NAfTJessC0ei5+6r=ug@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Olivier Forget <teleclimber@gmail.com>, Ben Peters <Ben.Peters@microsoft.com>, Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Sat, Jan 24, 2015 at 9:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> Though I believe browsers will soon have much more pressure to support
> multiple ranges as a matter of course, as increased design with
> Flexbox and Grid will mean that highlighting from one point to
> another, in the world of "a range is defined by two DOM endpoints and
> contains everything between them in DOM order", can mean highlighting
> random additional parts of the page that are completely unexpected.
> Switching to a model of "visual" highlighting for selections will
> require multi-range support.
>
> In other words, it'll switch from being a rare thing to much more common.

Most sites will probably not use flexbox or grid for a long time to
come, and on sites that do non-contiguous selections will probably be
rare, so I wouldn't rely on this as a mitigating factor.  I once went
through some common selection use-cases with the new selection API
that I suggested before (returning a list of selected nodes or such),
and for at least some common cases (like "wrap the selection in a
<span>") it handled non-contiguous selections automatically, and was
easier to use as well.  For typical selection use-cases, the author
wants to deal with the selected nodes anyway, not the endpoints.
Received on Sunday, 25 January 2015 11:58:41 UTC

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