On 06/06/2014 18:52 , Ryosuke Niwa wrote:
On Jun 6, 2014, at 6:40 AM, Robin Berjon <ro...@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
