DIsjoint ranges (was: contentEditable=minimal)

On 06/06/2014 18:52 , Ryosuke Niwa wrote:
> On Jun 6, 2014, at 6:40 AM, Robin Berjon <robin@w3.org> wrote:
>> On 05/06/2014 09:02 , Ryosuke Niwa wrote:
>>> I agree visual selection of bidirectional text is a problem
>>> worth solving but I don't think adding a generic multi-range
>>> selection support to the degree Gecko does is the right
>>> solution.
>>
>> I'd be interested to hear how you propose to solve it in another
>> manner. Also note that that's not the only use case, there are
>> other possibilities for disjoint selections, e.g. a table
>> (naturally) or an editable surface with a non-editable island
>> inside.
>
> Supporting disjoint range is probably necessary but adding the
> ability to manipulate each range separately seems excessive because
> that'll lead to selections with overlapping ranges, ranges in
> completely different locations that are not visually disjoint, etc...
> We might need to do something like exposing readonly multi-range
> selection.

Readonly multiranges may be an option, but I can think of some issues 
(which perhaps we can address).

Several people have mentioned the use case in which a script wants to 
observe selection changes in order to ensure that selections conform to 
certain constraints. Consider the following:

   abc 2 defg
   ABC 1 defg

Let's imagine that the script wishes to constrain the selection to only 
that second line, that the user clicks at 1 and drags towards 2. You'd 
want the script to constrain the range such that it just selects "ABC ". 
If you only cancel the selection change, presumably it doesn't select 
anything at all here (and I'm also presuming that with such a gesture 
you don't get a selection change event for each character in between the 
two drag points — that would be a lot).

What is weird in this scenario is that so long as the text is 
unidirectional you can manipulate the range, but the second "B" is a 
character in a different direction you can't. (And then again, *only* in 
browsers that support visually continuous selection across bidi 
boundaries — in others it would still work.)

I don't think that this variability is good; it is likely to surprise 
developers.

Another issue is that in some cases I believe that *visually* disjoint 
selections are the right thing to do. If you have an editing host that 
contains a readonly island, it should be possible for the author to make 
that island non-selectable so that you can select text from one side to 
the other but not the island itself. (Typically this enables the 
inlining of affordances.)

Reconsidering your objection, I wonder if it really is a problem? 
Overlapping ranges: well, it would be weird, but basically it strikes me 
as a "doctor it hurts when I do this" problem, unless I'm missing 
something. Ranges in completely different locations that are not 
visually disjoint: well, if you do that, maybe you have a reason? Just 
because you can do something stupid with an API doesn't mean that it's a 
stupid API.

>>> For starters, most of author scripts completely ignore all but
>>> the first range, and applying editing operations to a multi-range
>>> selection is a nightmare.
>>
>> I don't disagree that it can be hard to handle, but I'm not sure
>> that that's indicative of anything. Most scripts only handle one
>> selection because AFAIK only Gecko ever supported more than one.
>
> Given Gecko itself doesn't handle applying editing operations to
> multiple ranges well from what I've heard, I'm not certain we can
> expect web developers to get them right especially in the context
> where disjoint multi-range selection is needed; e.g. bidirectional
> text, exotic layout model.

I don't think that what is supported in any browser today in terms of 
contentEditable should be seen as a limitation on what Web developers 
can achieve. I'm very much certain that they can do better.

Thinking about this some more, I wonder if the problem is not less 
common than I initially thought, though. If you consider the following text:

   ltr rtl ltr

You definitely need multiranges while the selection is in progress if 
you want visual continuity:

   [ltr rt]l ltr

But when both ends of the selection are in text with the same direction, 
you can revert to having a single range:

   [ltr rtl ltr]

The problem being less common does not decrease the need to support for 
it, but it does decrease the odds that people will shoot themselves in 
the foot over relatively common cases.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 23 June 2014 15:23:59 UTC