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

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.

Received on Saturday, 17 January 2015 16:56:10 UTC