On Mon, Mar 11, 2013 at 8:32 PM, Peter Kasting <pkast...@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- _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev