On Mon, Mar 11, 2013 at 5:32 PM, Peter Kasting <[email protected]> wrote:
> On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa <[email protected]> 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
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
