Re: DIsjoint ranges (was: contentEditable=minimal)

On Jun 23, 2014, at 8:23 AM, Robin Berjon <robin@w3.org> wrote:

> 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.

One of the biggest problems with the existing editing API is that it's hard to use because it's high level and a lot of things could go wrong unless you're very careful.  I don't think we want to introduce a yet another hard-to-use API if we can avoid it.

>>>> 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.

Again, I have a hard time believing that a novice Web developer who has never seen bidirectional text in his life could get this right.  It's the same issue as accessibility or IME issue we've been discussing in another thread.  It's extremely easy to get corner cases wrong.  Given the whole issue with the existing editing API is that it's buggy in edge cases, we need to be extremely careful not to introduce a yet another API that's error-prone.

> 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.

It is very common for a selection to contain both LTR and RTL text in bidirectional text context because numbers are always LTR in both Arabic and Hebrew.

- R. Niwa

Received on Monday, 30 June 2014 23:48:47 UTC