[webkit-dev] Overtype mode in WebKit for editable content?

[Shezan Baig]

On Tue, Mar 12, 2013 at 12:18 AM, Ryosuke Niwa <rniwa at webkit.org> 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.