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

[Shezan Baig]

On Mon, Mar 11, 2013 at 8:32 PM, Peter Kasting <pkasting at google.com> wrote:
> I question whether it makes sense at all from a user's perspective.  Users
> don't know or care what classes are used to implement their applications,
> they care what the applications do.  And from that perspective Windows is
> all over the place.  Wordpad, Word, and Visual Studio all support overtype
> mode, but all three do it differently (Visual Studio is IMO the best -- it
> actually changes the cursor from bar to block in overtype mode, which I'd
> love to see any other app supporting this to adopt, and certainly would want
> if we turned this on in Chrome for Windows).  Notepad, which to almost any
> user who doesn't open files with LF line endings is the same thing as
> Wordpad, doesn't, and neither does Firefox or Chrome (today).  Third-party
> editors are all over the place.
>
> I think we should decide this based on what is most helpful and least
> confusing to users.  Normally a platform convention is a way of establishing
> what users will expect, which is why it has any value at all.  Here I'm not
> convinced there's a user expectation of overtype mode in general, and I
> definitely worry that it has low utility and high annoyance, which make me
> greatly hesitate.  And implementing it for "rich text" but not "plain text"
> on the web seems like a recipe for confusion too -- do normal users
> understand the distinction and would expect overtype mode in one but not the
> other?  Seems more likely that some people would be frustrated that overtype
> mysteriously doesn't work sometimes, while others would be confused why
> every once in a while their text gets eaten, but not in a way they can
> reproduce consistently.



I feel like I should give some background to this discussion.

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).
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.

Regardless of whether WebKit will support overtype mode or not, our
application will support it because our users expect it to.  However,
we want to keep the diff between upstream and our fork to be as small
as possible.  Also, to me it seems like we would be going against the
principle of opensource software if we keep these features in our own
private fork only, since it is something that can be useful to the
general community.

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?

Thanks,
-shez-