On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa <[email protected]> wrote: >> Have you tested your code with bidirectional text? I don't think using >> block caret will work due to the way offsets at bidi-level boundary works in >> WebKit. In particular, suppose we have, in the document/byte order, ABC123 >> where ABC are strongly RTL letters in a LTR block. Then this text is >> rendered as: >> 123CBA >> >> If we were to place logical/DOM offset at where they appear visually, we >> have: >> (0)1(1)2(2)3C(5)B(4)A(3)(6) > > > Oh oops, I'm sorry. I messed this up. It should be: > (0)1(5)2(4)3C(2)B(1)A(3)(6) > instead. > >> i.e. At offset 3, the caret will visually appear on the right of "A". If >> you were just setting the caret width, the caret will look as if we're >> inserting a character on the right of "A", which is extremely misleading to >> a user.
Our application right now doesn't allow for bidi text, so this isn't currently an issue for us. I haven't looked at the details, but if we were to support this in the future, I think the caret rendering code would simply determine whether the next character is RTL or not, and if so, it would extend its width in the opposite direction. Also, I don't understand why offset 3 would be rendered after A -- shouldn't it be rendered before 1 since that is where the next character would be inserted? (or maybe between 3 and C, I'm not familiar enough with the bidi rules). If it is rendered after A right now, then I'm guessing that is just a bug, and whether or not the caret is 1px or 20px wide seems equally misleading to the user. _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
