[webkit-dev] Overtype mode in WebKit for editable content?
rniwa at webkit.org
Mon Mar 11 17:54:07 PDT 2013
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...
More information about the webkit-dev