On Anchored Selections in Windows, Gnome, and Mac OS X
April 28, 2009 by Dmitry
Pierre Igot wrote a blog post “Shrinking and expanding selections in Mac OS X” (via Daring Fireball), in the first part of which he explains how text selection works on Mac OS X, and complains that this behavior is wrong. I disagree.
Let me explain. On Windows and Gnome, when you’re selecting text with mouse, the anchor is being placed on the final point of your selection (and it’s displayed with a blinking indicator in some applications like Notepad). If you select text from left to right, the anchor appears at the end of your selection:
If you go from right to left, the anchor is at the beginning of it:
Pierre writes:
What if I overshot by one character or two and actually only wanted to select the first two words? To me, since the selection with the mouse was made from left to right, intuitively I should be able to shrink the selection by one or two characters by pressing shift-Left a couple of times on my keyboard.
This seems logical: if you go left to right, you’ll probably miss a character of two, so placing anchor to the end of your selection is the right way. But this logic is flawed. It’s no harder to miss a character when you begin selecting text, than to miss it when you finish. Actually, there’s no way to select missing characters at the beginning at all, apart from starting your selection from scratch. There’s also a problem with double-clicking the word. Where should be the anchor placed in this case? Windows places it at the end of the word, while Gnome places it at the beginning.
Cocoa text controls behave differently. When you select text with mouse, the anchor is undefined. When you switch to keyboard, you control the anchor point: if you start by pressing Shift+Right, the anchor is being placed at the end of your selection, but with Shift+Left it’s being placed at the beginning. This way you can easily select missing characters in any part of your selection. Also, without anchor, you can continue growing your selection both ways.
Notice that I didn’t say that Mac OS X behave differently, just Cocoa. Carbon handle this the third way (the anchor is always where you click), but Apple is getting rid of it. That’s why Finder has anchored text selection with mouse. Good thing there are rumors that it’s being rewritten in Cocoa for Snow Leopard.
Yes, there’s inconsistency between text selection and list selection, but I have no explanation for this :)
Update: Pierre published a follow-up.
Liked this post? Subscribe to RSS feed (or by email) and get more.
Mémoires
Video Mémoires
BlogJet
ScreenSketcher
As indicated in my post, the most frustrating aspect of all this is the unpredictability. Maybe one day all Apple applications and even all Mac OS X applications will behave the same way, but until that day, having to constantly adjust one’s habits depending on which application one is using will remain frustrating.
And your lack of explanation of the inconsistency between text selection and list selection illustrates another aspect of the problem, which is that it does not appear to have been thought through. There is no reason why there should be an inconsistency. Yet more mental adjustments required all the time.
In answer to your explanation itself, I would argue that users probably focus more on the accuracy of their clicking for the beginning of the selection as opposed to the end, for the simple reason that it’s more difficult to be accurate when one of your hand’s fingers is pressing on a mouse button (i.e. while dragging). The initial click is probably more accurate simply because there is no tension in the hand resulting from having to press on something.
This would have to be backed up by actual scientific evidence, of course, but I do wonder whether it has even been considered by whoever made the decision to remove anchoring in Cocoa.
In Safari Beta 4 on OS X 10.5.6 - I presume this is cocoa but I could well be wrong: • If you select-drag text then shift+arrow selects more text in the direction of the arrow. • If you double click to select a single word then shift+arrow selects more text in the direction of the arrow starting from the EXACT point of the cursor when double clicking. • triple click selects a paragraph and then shift+arrow selects more text in the direction of the arrow starting from the EXACT point of the cursor when triple clicking.
In TextEdit - which I guess is not Cocoa since it behaves differently than Safari but I could be wrong: • If you select-drag text then shift+arrow selects more text in the direction of the arrow. • If you double click to select a single word then shift+arrow selects more text in the direction of the arrow. • triple click selects a paragraph and then shift+arrow selects more text in the direction of the arrow.
I like the way TextEdit workst Safari could be different due to the nature of HTML - I have no idea really.
Cheers, Leish
“placing anchor to the end of your selection is the right way. But this logic is flawed. It’s no harder to miss a character when you begin selecting text, than to miss it when you finish”
Wrong. It’s not about correcting missed characters. It’s about what makes sense!!
@Leigh If you add in the control and option keys while selecting using shift and the arrow keys, you can get even more options with odd actions.
@Igot
There is no reason why there should be an inconsistency. Yet more mental adjustments required all the time.
If those are the kind of “mental adjustments” you have to do in your workflow, then Apple did a truly truly deeply fine job.
List selection in Leopard drives me batty!
If I use shift+down to select a list in Finder, shift+up should =deselect= the last item rather than adding an item above the anchor.
Move down one, up reverses that. How…novel. Grrrrr!
I’ve been liking the way my mac uses the text selection, as I often find especially in Word in Windows that the whole word selection seems rather clumsy, especially when all I want to get us part of a long URL, or a small segment of a longer word. Aslo being left haded, I usually drag from right to left.
Leish, both are Cocoa, and TextEdit’s behavior is how a Cocoa app would behave if it used the standard Apple-provided controls. Safari’s behavior is a incorrect, presumably due to it being implemented differently.
Thanks for the explanation of Cocoa’s. Text selection on my mac now makes sense to me. List selection, of course, is another story. How does growing a selection in both directions (like in iTunes) ever make sense? What is a scenario where that behavior is useful?
Hey, wondering if anyone knows of a mac app that allows me to hijack the MacOSX text select parameters. I deal with a lot of copying and pasting of code and customer passwords that contain dashes, underscores and various punctuation. I would love to have double-clicking on text select everything between spaces, instead of breaking at punctuation.