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

I thought a bit of the same thing as Tab when I saw the visual focus
discussion in CSS WG, but my current conclusion is not to think the
two the same thing. Focus may be possible, but selections is a
different thing.

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.

I actually like multi-selections. Visual Studio allows me to select
multiple ranges, and when I type, it changes all of them at once, just
like the replace-all command. That's really a nice feature. But as you
can see in this example, operations would behave differently against
multi-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.

/koji

On Sun, Jan 25, 2015 at 8:57 PM, Aryeh Gregor <ayg@aryeh.name> wrote:
> 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 Tuesday, 27 January 2015 14:32:19 UTC