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

[Ryosuke Niwa]

On Mon, Mar 11, 2013 at 5:32 PM, Peter Kasting <pkasting at google.com> wrote:

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

This is a very subjective topic to which I rather not respond.

Having said that, I object to implementing a behavior doesn't match
"RichEdit" or "Edit" window classes on Windows. We should match either
native edit window class.

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