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

[Ryosuke Niwa]

On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig <shezbaig.wk at gmail.com> wrote:

> We are in the process of porting our native Windows application from
> using a proprietary rendering framework to using WebKit as our
> rendering framework.  Our application is not Chrome, neither is it
> Safari, Firefox, or Opera.  In fact, it isn't a web browser at all.
>
> Throughout this effort, we've come across many instances where we have
> had to modify WebKit in order to make our application work the way our
> users expect it to.  All these changes are maintained in our own
> private fork, which we frequently merge with upstream.
>
> Yes, our users *do* expect overtype mode to work, and yes, we do want
> a blinking block cursor, however I consider that as an orthogonal
> setting and not necessarily tied to overtype mode.  The way I
> envisioned this would be that the embedding application would set a
> property on the contenteditable div to turn on/off the overtype mode,
> based on some UI interaction (whether it is via the Insert key, or
> some menu command is up to the application).  When the contenteditable
> is in overtype mode, this essentially makes TypingCommand replace the
> next character instead of inserting characters.  This is a behavior
> change *only*, not a visual change.
>
> When the application switches the overtype mode on/off, it would also
> at the same time modify the appearance of the cursor (in our app, this
> will be done via non-standard css properties, like "caret-width" and
> "caret-color", and yes, we only plan use this for fixed-width fonts).
>

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)

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.

It might also change the border color of the contenteditable.  My
> point is that the visual appearance to indicate that we are in
> overtype mode is not something I would expect WebKit to control.  So
> I'd rather leave discussion of the appearance separate from the
> functionality/behavior itself.
>

I agree with that statement but letting applications mess with the
shape/color of caret is a dangerous game to play since a lot of application
developers don't know how CJK and RTL text work in WebKit.

So I guess the question boils down to something like: if we have
> changes that are generally useful, but not used in the major WebKit
> applications (i.e. Chrome, Safari, Opera), does it make sense to
> upstream it to WebKit for the benefit of the general community?
>

Yes. It makes a lot of sense for this feature to be in WebKit. We can
probably expose some member functions on Editor or add new execCommand only
executable via menu/keyboard binding to toggle this feature.  I don't think
it makes a sense for WebCore to detect Insert Key and automatically move
into the inse

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