> >> what's the use case driving this, and where are the requirements
> >> coming from?
> >>
> >> i ask because i'm inclined to think that the circumstances in which
> >> this would a produce useful results, given the way it carves up the
> >> actual content, are quite, perhaps extremely, limited.
> >
> > Well, the web platform "supports" editing, text selection, and
> > drag-and-drop/copy-and-paste, etc. through various APIs. The question
> > is how those should work with RTL content.
> my question was specifically, why do it in a non-standard way for bidi text?
> (typical scenario is split visual but one range internally)

I can understand why the question might occur, or at least why it might occur 
now. Logical selection, as mentioned in various responses, including Mati's, is 
much more convenient to implement on an API or coding level--and has the 
benefit that the selection is aligned with the actual structure/meaning of the 
text. But it is more difficult to implement the display and interface for 
logical selection, particularly on mobile displays where the "mouse" is a 
person's finger. The user cannot see through their finger when performing 
selection and the selection "handles" and highlights are a lot more complicated 
both to draw and for users to understand. This appears to make visual selection 
appealing--although it doesn't, for the reasons mentioned elsewhere, lead to 
sensible text operations unless the selected run happens to be all in a single 


Reply via email to