- From: Phillips, Addison <addison@lab126.com>
- Date: Sat, 15 Aug 2015 21:24:48 +0000
- To: Richard Ishida <ishida@w3.org>, Anne van Kesteren <annevk@annevk.nl>
- CC: Ryosuke Niwa <rniwa@apple.com>, public-webapps <public-webapps@w3.org>, Ehsan Akhgari <ehsan@mozilla.com>, Aryeh Gregor <ayg@aryeh.name>, public-editing-tf <public-editing-tf@w3.org>, "www-international@w3.org" <www-international@w3.org>
> >> 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 direction. Addison
Received on Saturday, 15 August 2015 21:25:27 UTC