RE: Copying multi-range selection
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
Re: Copying multi-range selection
On Sat, Aug 15, 2015 at 9:04 PM, Richard Ishida ish...@w3.org wrote: my question was specifically, why do it in a non-standard way for bidi text? (typical scenario is split visual but one range internally) Which is not great for users, right? Also, as Addison points out, it's unclear how that would work on a touch screen. The reason it came up is that with new CSS features, this problem now also affects the LTR population. Which is kind of a sad state of affairs for that to be the reason this gets looked at... Also, while I'm here, thank you Mati, that is a great reply! -- https://annevankesteren.nl/
Re: Copying multi-range selection
We worked on this some years ago, and found that the cut/copy/paste were very, very complicated to get to be natural, and ended up dropping it. The problem is that if ...ABC... are adjacent ranges on the screen in the source (each letter is a range), people expect to see ...ABC... when it is pasted in to replace ...EFG You end up having to do a reverse bidi to see what combination of characters could produce the end result. Might be possible, but would need some serious UI research... Mark https://google.com/+MarkDavis *— Il meglio è l’inimico del bene —* On Sat, Aug 15, 2015 at 7:19 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range selection. There has been quite a bit of discussion about how we can better expose that to the Web since the current model of exposing a list of Range objects doesn't seem to be working well. However, another important question I have is how copying such a selected content work? Do we just stitch together disjoint content? But that may result in the content being pasted in completely different order. I copied www-international. Somewhat curious if this problem has been studied before. It does seem like you would have to add/remove formatting code points as the context where you paste may be different from the context where you copied from. -- https://annevankesteren.nl/
Re: Copying multi-range selection
On 15/08/2015 06:19, Anne van Kesteren wrote: On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range selection. There has been quite a bit of discussion about how we can better expose that to the Web since the current model of exposing a list of Range objects doesn't seem to be working well. However, another important question I have is how copying such a selected content work? Do we just stitch together disjoint content? But that may result in the content being pasted in completely different order. I copied www-international. Somewhat curious if this problem has been studied before. It does seem like you would have to add/remove formatting code points as the context where you paste may be different from the context where you copied from. 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. ri
Re: Copying multi-range selection
Hi Anne, Not sure if this would answer your question, but in general, when it comes to BiDi you need to differentiate between the physical order (what is in memory, e.g, ABC) and the logical order (what the user expects to see (e.g., CBA). At the same time to handle copy/paste, you will be considering both. For example, if you are copying the bidi text, it will be in the logical order. But to implement the replace, you will be working with the Physical order form of the text. Hope this helps. Wafaa On ١٥/٠٨/٢٠١٥, at ٠٨:٢١, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range selection. There has been quite a bit of discussion about how we can better expose that to the Web since the current model of exposing a list of Range objects doesn't seem to be working well. However, another important question I have is how copying such a selected content work? Do we just stitch together disjoint content? But that may result in the content being pasted in completely different order. I copied www-international. Somewhat curious if this problem has been studied before. It does seem like you would have to add/remove formatting code points as the context where you paste may be different from the context where you copied from. -- https://annevankesteren.nl/
Re: Copying multi-range selection
On Sat, Aug 15, 2015 at 8:38 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida ish...@w3.org wrote: 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. I see. I also think that it would be good to see some actual use cases. Not because I don't think one should handle it, but because the use cases may make us understand more what this is about and give an indication of what this could be useful for. The question of how to handle it, as I understand it, is not about the case when an element with one particular text direction is a descendant of one that is going the opposite direction and the user has selection the entire outer element, but about the case where the user selects a part of an ltr element and a part of an adjacent rtl element at the same time, correct? As for spending time on this on the editing F2F: If we manage to eliminate many of the tickets we currently have on the new editing specs before the F2F, then we should have more time for other things. It is first priority though that we do work through those things that we set out to work on (the CE Events spec and the input events spec). Many times it has now shown that we actually don't disagree about many of the issues, or can agree to a text, once we have a concrete proposal. So feel free to offer concrete proposals of how to change the spec text in the issues that are still open or by means of pull requests. That way we may be able to boil the controversies down to the things that we actually disagree on, and then focus on those at the F2F. I am fine with starting the meeting at 10 am on Sunday. . -- https://annevankesteren.nl/ -- Johannes Wilm Fidus Writer http://www.fiduswriter.org
Re: Copying multi-range selection
On Sat, Aug 15, 2015 at 10:23 AM, Richard Ishida ish...@w3.org wrote: 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. -- https://annevankesteren.nl/
RE: Copying multi-range selection
Hello, Anne! *** WARNING: longish comment, best left to readers really interested in bidi stuff *** This problem is well known in bidi circles, and as far as I know, has not been solved satisfactorily, and maybe even has no good solution. The heart of the problem is that a visually contiguous range may not be logically contiguous (i.e. contiguous in memory, or in DOM order), and vice-versa. If I am not mistaken, the number of disjoint visual segments corresponding to a contiguous logical range may reach 1 + twice the difference between the highest and the lowest embedding levels included in the range. I am not sure about the other way around, i.e. how many disjoint segments might correspond to one contiguous visual range; I suspect that it is the same formula. Anyway, this is more than one, thus a challenge. There is a long standing discussion between advocates of logical selection (the selection should be contiguous in memory but may be disjoint in display) and visual selection (the selection should be visually contiguous, but may cover disjoint segments in memory). Logical selection is often surprising and awkward to handle for the user. Visual selection is much easier for the user, but may arbitrarily glue pieces of text which are not logically connected, and would be heard not consecutively when you pronounce the sentence. I like to say that visual selection is an intuitive way to perform something which does not make much sense, and will seldom be useful (see Richard Ishida's request for use cases). From what I have seen, not many implementers have chosen to support visual selection. I seem to remember that some versions of MS Word offered an option to choose between logical and visual selection, and that the visual selection was rather buggy. So most implementations are of logical selection, but let us ignore the nonsense intrinsic in visual selection and consider how it should work in a copy/paste operation. The objective should be for the selected text to appear at the destination exactly as it is displayed at the source. To achieve that for bidi text, we might need to use directional hints, such as Unicode directional control characters, or markup. So the source application should know whether the destination application supports such directional hints, and which ones. MS Word has an option whether to add control characters in Cut and Copy. Even when using directional hints, there should be the minimum needed to achieve the proper display. It is not possible for the source application to determine this minimum without knowing the context of the destination. So the source application should bracket the selected text with enough directional hints to make sure it is displayed properly in whatever context exists at the destination, and the destination application should be smart enough to remove part or all of these hints if they have no visible effect where they are inserted. This is not impossible, but not simple either. If the destination application does not support directional hints, the visual text should be transformed to the logical text which will give the same display without adding any directional controls. There are inherent problems: - It is necessary to know the bidi embedding level (which in simple case is the paragraph direction) at the destination. - Some visual configurations cannot be the representation of any logical sequence without the help of directional controls. For instance the visual string abc DEF 123 in a left-to-right context, with abc representing LTR text and DEF representing RTL text. An example in right-to-left context could be the visual string 123 abc DEF. I hope this helps. -- Shalom (Regards), Mati -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Saturday, August 15, 2015 8:20 AM To: Ryosuke Niwaa Cc: public-webapps; Ehsan Akhgari; Aryeh Gregor; public-editing-tf; www-internatio...@w3.org Subject: Re: Copying multi-range selection On Sat, Aug 15, 2015 at 12:10 AM, Ryosuke Niwa rn...@apple.com wrote: We've been recently exploring ways to select bidirectional text and content that uses new CSS layout modes such as flex box in visually contagious manner. Because visually contagious range of content may not be contagious in DOM order, doing so involves creating a disjoint multi-range selection. There has been quite a bit of discussion about how we can better expose that to the Web since the current model of exposing a list of Range objects doesn't seem to be working well. However, another important question I have is how copying such a selected content work? Do we just stitch together disjoint content? But that may result in the content being pasted in completely different order. I copied www-international. Somewhat curious if this problem has been studied before. It does seem like you would have to add/remove formatting code points as the context
