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

Ryosuke Niwa rniwa at webkit.org
Mon Mar 11 21:11:38 PDT 2013

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:

If we were to place logical/DOM offset at where they appear visually, we

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>

More information about the webkit-dev mailing list