En 12/04/13 18:17, Ryosuke Niwa escribiu: > On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin <svil...@igalia.com
> For example consider the strongly LTR letters > "abc" inside a RTL block, which will be rendered as "abc". If we either > place the caret at the beginning (before 'a') or at the end (after 'c') > the next typed character will be placed at the opposite side the user > might expect based on the caret position. > > > That's expected. I know it's expected :) but that does not mean that characters appearing at remote locations (from caret POV) is not weird. I know that WK follows the NSTextView implementation but FF for example does not show the remote insert issue. > The problem here is that caret will be on top of a wrong character. > That's much worse than a character being inserted at a remote location. > Using my existing example, what user sees is: > 123CBA or 123CBA > yet what will be replaced is 1. That's insane. > > This is orders of magnitude worse than caret showing up as a vertical > line at this location: > 123|CBA Yeah I understood you example, it was very descriptive. What I wanted to share with you is that, in your same example, in "Insert" mode, placing the caret at (3) will insert the next character before the 1. Isn't that insane too? > And this is why just setting the width of caret will never work. Well, I have a pretty compact patch more or less ready to be uploaded to bz that in the case of the caret being placed at (3) just draws the classical 1px width bar (it also draws the thin bar in the case of being after the last character), so although the replaced character is in any case the 1, the insanity you mention is somehow minimized. BR _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev