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

[Ryosuke Niwa]

On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin <svillar at igalia.com>wrote:

> En 12/03/13 18:31,
> - R. Niwa
> escribiu:
> > That doesn't work. At a bidi-level boundary, offset can jump from one
> > place to another. Consider a much simpler example; the same sequence of
> > letters, in logical order, ABC123 in a RTL block, which will be rendered
> as:
> > 123CBA
> > with logical/DOM offsets placed at:
> > (6)1(4)2(5)3(3)C(2)B(1)A(0)
> >
> > Again, at offset 3, what we're going to replace is "1" so we can't place
> > the block caret on top of either "C" or "3".
>
> The problem is that such kind of "weird" behaviors are happening now
> without overtype mode.


No.

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.

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

And this is why just setting the width of caret will never work.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/33b27058/attachment.html>