Who loves multiple selection feature in editor?

[Masayuki Nakano]

At investigating selection API behavior, I realized that non-Gecko
engines don't support multiple selection.

For example, document.getSelection().addRange(somethingNewRange) does
nothing when the selection has a range.

You can see the behavior with following testcases:
1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/
2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/

Personally, I like the multiple selection feature when I copy a lot of
fragments of a document. However, who needs this feature in editor?
Supporting multiple selection in editor makes our editor code
complicated. For example, when web apps try to make the text content
bold, editor needs to do it at every selection range. If selection is
modified during handling something, loop for selection ranges may cause
crash (I've seen a lot of similar crash bugs).

So, it might be better to stop supporting multiple selection only in
editor if the feature is not so loved by users.

I filed a bug for discussing this issue here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681

Feel free to comment anything.

Thanks in advance.

--
Masayuki Nakano <masa...@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

[Ehsan Akhgari]

On 2016-12-15 4:46 AM, Masayuki Nakano wrote:
> At investigating selection API behavior, I realized that non-Gecko
> engines don't support multiple selection.
>
> For example, document.getSelection().addRange(somethingNewRange) does
> nothing when the selection has a range.
>
> You can see the behavior with following testcases:
> 1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/
> 2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/
>
> Personally, I like the multiple selection feature when I copy a lot of
> fragments of a document. However, who needs this feature in editor?
> Supporting multiple selection in editor makes our editor code
> complicated. For example, when web apps try to make the text content
> bold, editor needs to do it at every selection range. If selection is
> modified during handling something, loop for selection ranges may cause
> crash (I've seen a lot of similar crash bugs).
>
> So, it might be better to stop supporting multiple selection only in
> editor if the feature is not so loved by users.
>
> I filed a bug for discussing this issue here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1323681

We currently expose selections with multiple ranges at several levels:

* The developer facing APIs. As you have noted above, our selection API
allows you to construct and examine multi-range selections. This is
something that we should fix at some point, since other browser vendors
have been very clear that they won't implement this functionality (and I
think that's a good idea) so we're not interoperable with them on this
front.

* The user facing functionality. Currently we expose multi-range
selections to the user in the following ways (perhaps among others that
I'm missing?):

* Table cell selection (by Ctrl/Cmd-clicking on several table cells
allows you to select them all)
* Mouse based selection (by holding Ctrl/Cmd when selecting something
on a page with another selection present)
* (and perhaps touch based selection also similarly, but I don't have
a device I can test that on)

There is at least one good use case for this, which is copying things to
the clipboard, but if we decide to keep the user facing functionality,
then we should determine what to expose to developers when a multi-range
selection is made by users. There are several options, such as only
representing the first selection in the range, or the latest (last) one.

(I also wonder how many people even know about these ways to create
multi-range selections, given how undiscoverable they are! We should
probably add telemetry to measure their usage.)

* The interactions with the editor, which I definitely agree is a mess.
I'm not sure what you specifically mean by not supporting them. Given
that they are currently possible to create by the user, we need to
handle them _somehow_ in the editor code. I personally think we should
drop support for user made multi-range selections over editable regions
to guarantee that the editor code never actually hits this case...

* Gecko's internal usage of multi-range selections. We use multi-range
selections to implement some other selection types, including spellcheck
(which we use to mark the misspelled areas to be drawn with the red
squiggly line) and find (which we use to mark highlighted areas as the
result of using the find bar, which can create a multi-range selection
when using the Highlight All mode.) Clearly we can't drop support for
what we need to deal with spellcheck selections which are often
multi-range. Have you considered this in your plans?

I think we should probably ask other browser vendors about this again so
that we can plan our future here better.

Cheers,
Ehsan

[Botond Ballo]

On Fri, Dec 16, 2016 at 12:32 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> * The user facing functionality. Currently we expose multi-range
> selections to the user in the following ways (perhaps among others that
> I'm missing?):
>
> * Table cell selection (by Ctrl/Cmd-clicking on several table cells
> allows you to select them all)
> * Mouse based selection (by holding Ctrl/Cmd when selecting something
> on a page with another selection present)
> * (and perhaps touch based selection also similarly, but I don't have
> a device I can test that on)
>
> There is at least one good use case for this, which is copying things to
> the clipboard, but if we decide to keep the user facing functionality,
> then we should determine what to expose to developers when a multi-range
> selection is made by users. There are several options, such as only
> representing the first selection in the range, or the latest (last) one.
>
> (I also wonder how many people even know about these ways to create
> multi-range selections, given how undiscoverable they are! We should
> probably add telemetry to measure their usage.)

I didn't know about this feature! I think it's useful, though (for the
reason you mentioned: copying things to the clipboard; think
multi-quoting replies and such), and now that I know about it, I
expect I'm going to use it.

Cheers,
Botond

[Karl Dubost]

As Ehsan said:

Le 17 déc. 2016 à 02:32, Ehsan Akhgari <ehsan....@gmail.com> a écrit :
> (I also wonder how many people even know about these ways to create
> multi-range selections, given how undiscoverable they are! We should
> probably add telemetry to measure their usage.)

I know it for a very long time and it's very practical to me when I want for example to reply to a specific part of a text but don't want to copy, paste and trim.

It is one of these very useful features where Firefox is leading, but that we do not advertise this as user benefits. Missed opportunity. Instead of removing it I would probably vote for making it known ;)



--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

[glazou]

Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :

> So, it might be better to stop supporting multiple selection only in
> editor if the feature is not so loved by users.

We were already discussing this issue at Netscape 15 years ago but could not come up with a good solution at that time. Thanks for bringing it back, this could be the right time to finally solve it.

Some existing use cases:

1. this is absolutely needed for table cell selection. Everyone extensively using tables uses multiple selection at some point.

2. Microsoft Word on all platforms and in general all commercial Whysiwyg Text editors allow multiple selection.

3. multiple selection is really cool if you think of images representing videoframes you select to edit/crop a video.

4. "search a text" often ends with a multiple selection of all occurrences of the pattern in the document

On another hand, I think selection would benefit from a boolean attribute saying if the rendering engine allows or not multiple selection and if it does not, having shortcut mechanisms allowing to get rid of the onmipresent and painful getRangeAt(0). We do quite equivalent things when the selection is collapsed.

</Daniel>

[Ehsan Akhgari]

Note that this feature in editable regions is significantly broken.
While I sympathize with your feeling about the usefulness of this
feature outside of editable regions, I wouldn't want to expose it more
broadly before addressing the issues that this thread is discussing.

[Frederik Braun]

On 19.12.2016 17:19, glazou wrote:
> Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
>
>> So, it might be better to stop supporting multiple selection only in
>> editor if the feature is not so loved by users.
>
> We were already discussing this issue at Netscape 15 years ago but could not come up with a good solution at that time. Thanks for bringing it back, this could be the right time to finally solve it.
>
> Some existing use cases:
>
> 1. this is absolutely needed for table cell selection. Everyone extensively using tables uses multiple selection at some point.
>

I'm generally all for removing complexity and I hate to be a spoilsport.
But table cell selection is pretty useful (e.g., a full row, a full
column and the possibility of removing a few here and there)

> 2. Microsoft Word on all platforms and in general all commercial Whysiwyg Text editors allow multiple selection.
>
> 3. multiple selection is really cool if you think of images representing videoframes you select to edit/crop a video.
>
> 4. "search a text" often ends with a multiple selection of all occurrences of the pattern in the document
>
> On another hand, I think selection would benefit from a boolean attribute saying if the rendering engine allows or not multiple selection and if it does not, having shortcut mechanisms allowing to get rid of the onmipresent and painful getRangeAt(0). We do quite equivalent things when the selection is collapsed.
>
> </Daniel>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Johnny Stenback]

Unless we get clear buy-in from other browsers to support this I would vote
for removing this complexity out of Gecko.


- jst

On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun <fbr...@mozilla.com> wrote:

> On 19.12.2016 17:19, glazou wrote:

> > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> >
> >> So, it might be better to stop supporting multiple selection only in
> >> editor if the feature is not so loved by users.
> >
> > We were already discussing this issue at Netscape 15 years ago but could
> not come up with a good solution at that time. Thanks for bringing it back,
> this could be the right time to finally solve it.
> >
> > Some existing use cases:
> >
> > 1. this is absolutely needed for table cell selection. Everyone
> extensively using tables uses multiple selection at some point.
> >
>

> I'm generally all for removing complexity and I hate to be a spoilsport.
> But table cell selection is pretty useful (e.g., a full row, a full
> column and the possibility of removing a few here and there)
>
>

> > 2. Microsoft Word on all platforms and in general all commercial
> Whysiwyg Text editors allow multiple selection.
> >
> > 3. multiple selection is really cool if you think of images representing
> videoframes you select to edit/crop a video.
> >
> > 4. "search a text" often ends with a multiple selection of all
> occurrences of the pattern in the document
> >
> > On another hand, I think selection would benefit from a boolean
> attribute saying if the rendering engine allows or not multiple selection
> and if it does not, having shortcut mechanisms allowing to get rid of the
> onmipresent and painful getRangeAt(0). We do quite equivalent things when
> the selection is collapsed.
> >
> > </Daniel>

[Jared Wein]

We currently use multiple selections for highlighting the domain in the
location bar, as well as find-in-page "highlight all". What would you
recommend we do if this is removed? I don't see how we would implement
"highlight all" without it.

Thanks,
Jared

On Mon, Dec 19, 2016 at 3:52 PM, Johnny Stenback <j...@mozilla.com> wrote:

> Unless we get clear buy-in from other browsers to support this I would vote
> for removing this complexity out of Gecko.
>
>
> - jst
>
> On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun <fbr...@mozilla.com>
> wrote:
>
> > On 19.12.2016 17:19, glazou wrote:

> > > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> > >
> > >> So, it might be better to stop supporting multiple selection only in
> > >> editor if the feature is not so loved by users.
> > >
> > > We were already discussing this issue at Netscape 15 years ago but
> could
> > not come up with a good solution at that time. Thanks for bringing it
> back,
> > this could be the right time to finally solve it.
> > >
> > > Some existing use cases:
> > >
> > > 1. this is absolutely needed for table cell selection. Everyone
> > extensively using tables uses multiple selection at some point.
> > >
> >

> > I'm generally all for removing complexity and I hate to be a spoilsport.
> > But table cell selection is pretty useful (e.g., a full row, a full
> > column and the possibility of removing a few here and there)
> >
> >

> > > 2. Microsoft Word on all platforms and in general all commercial
> > Whysiwyg Text editors allow multiple selection.
> > >
> > > 3. multiple selection is really cool if you think of images
> representing
> > videoframes you select to edit/crop a video.
> > >
> > > 4. "search a text" often ends with a multiple selection of all
> > occurrences of the pattern in the document
> > >
> > > On another hand, I think selection would benefit from a boolean
> > attribute saying if the rendering engine allows or not multiple selection
> > and if it does not, having shortcut mechanisms allowing to get rid of the
> > onmipresent and painful getRangeAt(0). We do quite equivalent things when
> > the selection is collapsed.
> > >
> > > </Daniel>

[Mats Palmgren]

On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
> Supporting multiple selection in editor makes our editor code
> complicated.

Why is that so exactly? By necessity, the code already operates
on one Range, right? so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing
code to all the ranges? And for functions that doesn't make sense
to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.

Would that help solve the problem?

/Mats

[Mats Palmgren]

On 12/16/2016 06:32 PM, Ehsan Akhgari wrote:
> * The developer facing APIs. As you have noted above, our selection API
> allows you to construct and examine multi-range selections. This is
> something that we should fix at some point, since other browser vendors
> have been very clear that they won't implement this functionality

Quoting Ryosuke Niwa, the current spec author:
"As a vendor (Apple), we have quite a bit of interest in improving
selection for bidirectional text and new CSS layout modes such as flex
box and grid layout which can change the order of context. One way to
achieve that would be supporting multi-range selection.
As a spec author, there has been some discussion about bringing back
multi-range selection, there is no wide support nor consensus about it."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c5

Quoting Tab Atkins Jr. from the same bug:
"Yeah, Selection is just *silly* in common Grid cases under the old
'single start and end DOM locations' model. Need multi-range selection to
make it work."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c7

I've made an example Grid to illustrate that last point, try selecting
the first column then the second (first some A's then some B's)
(you need Nightly or DevEdition for the example to work):
https://people-mozilla.org/~mpalmgren/tests/grid/grid-selection.html
I agree with Tab that this is going to happen *a lot*.

I think we should work with Ryosuke to develop a better Selection API
so that handling multi-range Selection comes naturally. That part
doesn't seem that hard to me; the problem is mostly about getting web
developers to use the new API, but if we can make it just a little bit
nicer than getRangeAt() then I believe we can win them over.

> * The user facing functionality. Currently we expose multi-range
> selections to the user in the following ways (perhaps among others that
> I'm missing?):
>
> * Table cell selection (by Ctrl/Cmd-clicking on several table cells
> allows you to select them all)
> * Mouse based selection (by holding Ctrl/Cmd when selecting something
> on a page with another selection present)
> * (and perhaps touch based selection also similarly, but I don't have
> a device I can test that on)

* user selection over CSS '-moz-user-select:none' regions
* user selection in CSS Grid layout (eventually :-) )


/Mats

[Masayuki Nakano]

On 2016/12/20 6:21, Jared Wein wrote:
> We currently use multiple selections for highlighting the domain in the
> location bar, as well as find-in-page "highlight all". What would you
> recommend we do if this is removed? I don't see how we would implement
> "highlight all" without it.

I'm suggesting this issue only for normal selection (i.e.,
nsISelectionController::getSelection(nsISelectionController::SELECTION_NORMAL)).
Multiple selection for other selection types are necessary, e.g.,
SELECTION_SPELLCHECK, SELECTION_IME_RAWINPUT,
SELECTION_IME_SELECTEDRAWTEXT, SELECTION_IME_CONVERTEDTEXT,
SELECTION_IME_SELECTEDCONVERTEDTEXT and SELECTION_FIND. So, perhaps, you
don't need to mind about such feature.

(Although, I don't know which selection type is used in location bar.)

[Masayuki Nakano]

On 2016/12/20 8:00, Mats Palmgren wrote:
> On 12/15/2016 10:46 AM, Masayuki Nakano wrote:
> > Supporting multiple selection in editor makes our editor code
> > complicated.
>
> Why is that so exactly? By necessity, the code already operates
> on one Range, right? so why can't we implement something like:
> Selection.ApplyToAllRanges(aFunction) that applies the existing
> code to all the ranges?

That's a good point. Even if we won't remove multiple selection feature
from editor, we should rewrite *all* selection loop with such utility.

> And for functions that doesn't make sense
> to apply to all ranges, it's usually the first or last range
> you want, so let's make convenience functions for those too.

Makes sense!

> Would that help solve the problem?

I can say "yes" from the point of maintenance cost. But there is another
concern. Other browsers *ignore* Selection.addRange() when there is
already one range in the Selection. So, following code may be
incompatible with other browsers:

onSomething() {
let newRange = document.createRange();
newRange.setStart(foo, bar);

// If rangeCount is 0, the result on Gecko is same as other browsers,
// but not so if selection already has a range.
document.getSelection().addRange(newRange);

// Unexpected range (newRange) will be removed on Gecko, but the
// range may be a bug of web apps, but it won't be found with
// testing other browsers.
document.execCommand("delete");

[Masayuki Nakano]

On 2016/12/17 2:32, Ehsan Akhgari wrote:
> We currently expose selections with multiple ranges at several levels:
>

> * The developer facing APIs. As you have noted above, our selection API
> allows you to construct and examine multi-range selections. This is
> something that we should fix at some point, since other browser vendors

> have been very clear that they won't implement this functionality (and I
> think that's a good idea) so we're not interoperable with them on this
> front.
>

> * The user facing functionality. Currently we expose multi-range
> selections to the user in the following ways (perhaps among others that
> I'm missing?):
>
> * Table cell selection (by Ctrl/Cmd-clicking on several table cells
> allows you to select them all)
> * Mouse based selection (by holding Ctrl/Cmd when selecting something
> on a page with another selection present)
> * (and perhaps touch based selection also similarly, but I don't have
> a device I can test that on)
>

> There is at least one good use case for this, which is copying things to
> the clipboard, but if we decide to keep the user facing functionality,
> then we should determine what to expose to developers when a multi-range
> selection is made by users. There are several options, such as only
> representing the first selection in the range, or the latest (last) one.
>

> (I also wonder how many people even know about these ways to create
> multi-range selections, given how undiscoverable they are! We should
> probably add telemetry to measure their usage.)
>

> * The interactions with the editor, which I definitely agree is a mess.
> I'm not sure what you specifically mean by not supporting them. Given
> that they are currently possible to create by the user, we need to
> handle them _somehow_ in the editor code. I personally think we should
> drop support for user made multi-range selections over editable regions
> to guarantee that the editor code never actually hits this case...

My original idea was, to stop supporting multiple selection in editor
completely. I.e., users cannot add selection range by mouse operation
nor authors cannot add range like other browsers.

However, indeed, if user edits table, multiple selection might be
useful. Hmm...

> * Gecko's internal usage of multi-range selections. We use multi-range
> selections to implement some other selection types, including spellcheck
> (which we use to mark the misspelled areas to be drawn with the red
> squiggly line) and find (which we use to mark highlighted areas as the
> result of using the find bar, which can create a multi-range selection
> when using the Highlight All mode.) Clearly we can't drop support for
> what we need to deal with spellcheck selections which are often
> multi-range. Have you considered this in your plans?

I'm talking about only nsISelectionController::SELECTION_NORMAL. Other
selections need multiple selection.

The reason why our editor code becomes complicated is, multiple normal
selection ranges become "edit targets". For example, when you type a
character when there are multiple selection ranges, current editor
removes all ranges first. Then, inserts the character at first or last
range (I forgot which range is focused range).

At this time, we need to create loop for deleting all selection ranges,
but the ranges may be changed/removed during handling other selection
ranges. We don't have any spec how do we behave in such case.

> I think we should probably ask other browser vendors about this again so
> that we can plan our future here better.

I agree.

[Mats Palmgren]

On 12/15/2016 10:46 AM, Masayuki Nakano wrote:

> Supporting multiple selection in editor makes our editor code
> complicated.

Why is that so exactly? By necessity, the code already operates
on one Range, right? so why can't we implement something like:
Selection.ApplyToAllRanges(aFunction) that applies the existing

code to all the ranges? And for functions that doesn't make sense

to apply to all ranges, it's usually the first or last range
you want, so let's make convenience functions for those too.

Would that help solve the problem?

/Mats

[Mats Palmgren]

On 12/16/2016 06:32 PM, Ehsan Akhgari wrote:

> * The developer facing APIs. As you have noted above, our selection API
> allows you to construct and examine multi-range selections. This is
> something that we should fix at some point, since other browser vendors
> have been very clear that they won't implement this functionality

Quoting Ryosuke Niwa, the current spec author:
"As a vendor (Apple), we have quite a bit of interest in improving
selection for bidirectional text and new CSS layout modes such as flex
box and grid layout which can change the order of context. One way to
achieve that would be supporting multi-range selection.
As a spec author, there has been some discussion about bringing back
multi-range selection, there is no wide support nor consensus about it."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c5

Quoting Tab Atkins Jr. from the same bug:
"Yeah, Selection is just *silly* in common Grid cases under the old
'single start and end DOM locations' model. Need multi-range selection to
make it work."
https://bugzilla.mozilla.org/show_bug.cgi?id=1323681#c7

I've made an example Grid to illustrate that last point, try selecting
the first column then the second (first some A's then some B's)
(you need Nightly or DevEdition for the example to work):
https://people-mozilla.org/~mpalmgren/tests/grid/grid-selection.html
I agree with Tab that this is going to happen *a lot*.

I think we should work with Ryosuke to develop a better Selection API
so that handling multi-range Selection comes naturally. That part
doesn't seem that hard to me; the problem is mostly about getting web
developers to use the new API, but if we can make it just a little bit
nicer than getRangeAt() then I believe we can win them over.

> * The user facing functionality. Currently we expose multi-range
> selections to the user in the following ways (perhaps among others that
> I'm missing?):
>
> * Table cell selection (by Ctrl/Cmd-clicking on several table cells
> allows you to select them all)
> * Mouse based selection (by holding Ctrl/Cmd when selecting something
> on a page with another selection present)
> * (and perhaps touch based selection also similarly, but I don't have
> a device I can test that on)

[Mats Palmgren]

On 12/20/2016 03:25 AM, Masayuki Nakano wrote:
> I'm talking about only nsISelectionController::SELECTION_NORMAL. Other
> selections need multiple selection.

I suspect that treating SELECTION_NORMAL differently from other kinds of
Selections will actually make the code more complicated, not less.

> At this time, we need to create loop for deleting all selection ranges,
> but the ranges may be changed/removed during handling other selection
> ranges.

Is that due to notifying selection listeners? If so, there is a RAII
class for blocking those until you're done: SelectionBatcher.
Anyway, I believe that we can add a few convenience methods/classes
to make this stuff easy to work with...

But let's take that code discussion off-list. :-)

> We don't have any spec how do we behave in such case.

The current spec editor seems open to discussing multi-range Selection,
which is encouraging.

Perhaps we could add something like this:

selection.forEachRange(function (range) {
// do awesome stuff
})

Since web developers are essentially doing this today:
doAwesomeStuff(selection.getRangeAt(0));

it seems it should be an easy upgrade to do this instead:
selection.forEachRange(doAwesomeStuff);

Look, it's even shorter! :-)


/Mats

[Mike de Boer]

> On 20 Dec 2016, at 20:52, Mats Palmgren <ma...@mozilla.com> wrote:
>
> The current spec editor seems open to discussing multi-range Selection,
> which is encouraging.
>
> Perhaps we could add something like this:
>
> selection.forEachRange(function (range) {
> // do awesome stuff
> })
>
> Since web developers are essentially doing this today:
> doAwesomeStuff(selection.getRangeAt(0));
>
> it seems it should be an easy upgrade to do this instead:
> selection.forEachRange(doAwesomeStuff);

I’d also be looking forward to see the ‘broken' selection spec move forward!

Perhaps even more intuitive (and shorter) to use would be a DOMList selection.ranges that will be iterable (and mutable?), I think.
The selection world would unfold to:

```js
for (let range of selection.ranges) { … }

let range = selection.ranges.item(0); // or selection.ranges[0]
```

Mike.

[Ehsan Akhgari]

On 2016-12-19 6:59 PM, Mats Palmgren wrote:
> I've made an example Grid to illustrate that last point, try selecting
> the first column then the second (first some A's then some B's)
> (you need Nightly or DevEdition for the example to work):
> https://people-mozilla.org/~mpalmgren/tests/grid/grid-selection.html
> I agree with Tab that this is going to happen *a lot*.

I admit that I don't understand CSS Grids, but looking at the markup, I
understand the use case. It's hard to think how this can be fixed
without multi-range selections.

This is actually a great example in that in invalidates my previous
suggestion about perhaps only not supporting user-made selections with
multiple ranges in editable areas. :-( It's unreasonable to expect
selections to be broken when editing a document that uses grids.

I think this may end up forcing our hand here. The only remaining
option that I can see is fixing our code to deal with multi-range
selections.

> I think we should work with Ryosuke to develop a better Selection API
> so that handling multi-range Selection comes naturally. That part
> doesn't seem that hard to me; the problem is mostly about getting web
> developers to use the new API, but if we can make it just a little bit
> nicer than getRangeAt() then I believe we can win them over.

The current API isn't the most modern but it is similar to many other
DOM APIs with a count attribute and a getter(index) method. What do you
think is wrong with it?

I don't think the assumption that the only thing that developers need to
change is the syntax they use to use another function such as
forEachRange() is necessarily correct. Depending on what the code does,
it may need restructuring to properly support multiple ranges. There
may be many assumptions around only a single range baked in the existing
code.

I think the much more interesting thing to focus on is defining the
semantics of multi-range selections in that spec. The semantics of
handling them in editing operation probably needs some consideration too.

>> * The user facing functionality. Currently we expose multi-range
>> selections to the user in the following ways (perhaps among others that
>> I'm missing?):
>>
>> * Table cell selection (by Ctrl/Cmd-clicking on several table cells
>> allows you to select them all)
>> * Mouse based selection (by holding Ctrl/Cmd when selecting something
>> on a page with another selection present)
>> * (and perhaps touch based selection also similarly, but I don't have
>> a device I can test that on)
>
> * user selection over CSS '-moz-user-select:none' regions

Ah, yes!

> * user selection in CSS Grid layout (eventually :-) )
>

Cheers,
Ehsan