[webkit-dev] Overtype mode in WebKit for editable content?
pkasting at google.com
Mon Mar 11 20:19:23 PDT 2013
On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Yes, we should disable triple-click-to-select-all on Windows
You realize that Wordpad, Word, and Internet Explorer all support this,
though, right? My point was not just to raise a behavior that seems like a
clear win, it was to reiterate that there's little connection between what
a control does and what users will expect to see. Triple-click is widely
used on Windows and taking it away would be clearly wrong from a user
> Granted, there are certain editing features that are hard to replicate
> native behavior (e.g. caret movements in bidirectional text) but those
> should still be considered as bugs.
There are also certain cases where the native control is just clearly
buggy. For example,CRichEditCtrl draws bad selection highlights and adds
an extra newline to the displayed string when used in single line mode,
apparently because Microsoft never actually used it in single line mode and
thus didn't test. There are other cases (which I forget) where certain
actions just cause bizarre behavior that makes no sense and is clearly
wrong. It makes no sense to me to replicate these sorts of things.
> I remember I was stunned by how selection was painted in Google Chrome on
> Windows when it was initially released because it violated the platform
> convention I was used to on Windows. There were quite few other
> editing-related features that struck me as unconventional such as the caret
> appearing before the space following a word when moving caret forward at
> word boundaries. All those tiny differences added up to the point where I
> decided not to use Google Chrome as my primary Web browser on Windows.
Things like the caret movement were clearly wrong. Everything everywhere
on Windows does caret movement a certain way and you're far from the only
person who had problems with those sorts of things (I complained to Ojan
about something like a hundred different such bugs). Even today there are
still some lurking bugs when trying to expand the selection range on
windows using shift+up or shift+down, and some other things that are
It's also worth noting that some behaviors cause usage issues and others
don't. Getting the caret movement wrong, for example, causes concretely
wrong output when someone attempts to rapidly edit text using the caret
movement shortcuts they're familiar with.
In the case of showing a blinking block cursor for overtype mode, not only
is Windows inconsistent about how it handles things, but this purely visual
change can't cause users to wind up with the wrong text. Indeed, the
entire point is to point out that overtype mode is enabled -- which is not
what the user intended 99% of the time anyway -- and help PREVENT incorrect
output more quickly.
> So I'm extremely skeptical when you say we can up with a superior way of
> doing something on Windows based on user expectations because user
> expectations are often shaped by other applications they use.
Thank you for reiterating my previous point: user expectations are shaped
by how things actually behave, not what the underlying controls implement
at a code level.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev