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

[Peter Kasting]

On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> Of course, each application can implement overtype in "Edit" window class
> and manually disable it in "RichEdit" window class but I don't think that's
> an interesting fact since that's a customization.  An application doesn't
> even have to use either window class to implement a "text field"; e.g.
> Microsoft Word.
>

(Word actually uses a rich edit control just like Wordpad does, which is
why Office ships a newer version of that control's DLL.)

But that doesn't mean there is no platform norm. Just like un-customized
> NSTextView establishes what's norm on Mac, un-customized "Edit" and
> "RichText" establish what's norm on Windows to a certain extent.
>

I think that might make sense from a programmer's perspective, though even
there I think you're on thin ice on Windows -- there are so many different
controls and frameworks for doing UI that the UX on Windows is much more
fragmented in general than on Mac (long one of the complaints of those who
prefer Mac OS).  I know what the MFC CEdit and CRichEditCtrl do, but I
don't anything about, say, WPF UIs.

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.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130311/b2db6613/attachment.html>