On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa <rn...@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 expectation perspective. > 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 obviously wrong. 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. PK
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
