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

I'd be interested in hearing more about what didn't work with that API by
both devs who tried to make use of it and the implementors too.

For the record: web developers don't usually take advantage of additional
functionality that is provided by only one browser, or implemented in
differing unpolished ways by different browsers. When possible we take the
lowest common denominator approach to offer a consistent experience from
browser to browser, and to avoid spending resources writing code that only
a subset of users will be able to use anyways.

What I'm saying is that the fact few devs worked with multiple ranges may
not be a reflection of the quality of the API, but rather that because it
wasn't implemented across browsers it wasn't worth from a cost-benefit
point of view.

And no I'm not saying the API is great either, just that saying "developers
won't do it" is not really fair to anybody.


On Sat Jan 17 2015 at 8:55:43 AM Aryeh Gregor <ayg@aryeh.name> wrote:

> On Mon, Jan 12, 2015 at 9:59 PM, Ben Peters <Ben.Peters@microsoft.com>
> wrote:
> > Multiple selection is an important feature in the future. Table columns
> are
> > important, but we also need to think about BIDI. Depending on who you
> talk
> > to, BIDI should support selection in document order or layout order.
> Layout
> > order is not possible without multi-selection.
> >
> >
> >
> > I do not believe “everyone wants to kill it” is accurate. I agree with
> > Olivier that it’s crucial to a full-featured editor. We don’t want to
> make
> > sites implement this themselves.
>
> If implementers are interested, then that's fine by me.  I was
> summarizing the result of a previous discussion or two I was aware of,
> and the current implementation reality.  However, I think thought
> should go into an API that supports non-contiguous selections without
> making authors try to handle the non-contiguous case specially,
> because they won't.  Exposing a list of selected nodes/parts of
> CharacterData nodes is a possibility that has occurred to me -- like
> returning a list of SelectedNodes, where SelectedNode has .node,
> .start, and .end properties, and .start and .end are null unless it's
> a partially-selected CharacterData node, and no node is in the list if
> it has an ancestor in a list.  So "fo[o<b>bar<i>baz</i></b>]quuz"
> would expose [{node: "foo", start: 2, end: 3}, {node: <b>, start:
> null, end: null}, {node: "quuz", start: 0, end: 0}] as the selected
> nodes.  Then authors would use it by iterating over the selected
> nodes, and non-contiguous selections would be handled automatically.
> I once thought over some use-cases and concluded that a lot of them
> would Just Work for non-contiguous selections this way -- although
> doubtless some cases would still break.
>
> (Obvious disadvantages disadvantages of this approach include a)
> authors will still continue using the old API, and b) calculating the
> list might be somewhat expensive.  (a) might be mitigated by the fact
> that it's easier to use for some applications, particularly
> editing-related ones -- it saves you from having to walk through the
> range yourself.)
>
> I certainly agree that non-contiguous selection is a good feature to
> have!  But as far as I'm aware, in Gecko's implementation experience,
> multiple Ranges per Selection has proven to be a bad way to expose
> them to authors.  Ehsan could tell you more.
>