April 22nd, 2009 • 6:38 pm
Nearly three years ago, Daring Fireball’s John Gruber wrote an excellent article about anchored and unanchored selection in Mac OS X, titled “Highly Selective.” (For definitions of anchored and unanchored selection, please refer to his article.)
Sadly, three years later, things are still a total mess in Mac OS X, even when one keeps the focus exclusively on Apple’s own software applications. If anything, it has become even more complex and confusing.
Consider what happens, for example, if you happen to switch from the mouse to the keyboard during the selection process.
In several of Apple’s text editors or applications with text editing tools (probably all based on the same underlying text editing engine), including Mail, TextEdit, but also Pages, Excel, etc., there is a total disconnect between the orientation of the mouse selection and the orientation of selection expansions with the cursor keys.
Take, for example, this sample paragraph of text in Pages:
If I now take my mouse and click at the beginning of the second sentence and drag my pointer to the right, I will create a text selection:
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.
Alas, that is not what happens. If I pressing shift-Left a couple of times, I get this:
Instead of shrinking the current selection by two characters from the right, Pages actually expands my selection by two characters from the left. In other words, it completely ignores the initial direction of my selection with the mouse (from left to right). To me, this seems to indicate that it’s an unanchored selection.
But unlike a “pure” unanchored selection (as per John Gruber’s definition), this is not a selection that “never shrinks.” If I now press shift-Right a few times, instead of expanding the selection to the right, Pages actually shrinks the selection from the left:
It gets even more interesting. The effect of the shift-Right and shift-Left shortcuts on this selection actually depends, not on the direction of the selection with the mouse (which Pages completely ignores), but on which of the two keyboard shortcuts is used first.
If shift-Right is used first, then Pages starts expanding the selection to the right:
After that, shift-Left can only be used to shrink the selection from the right:
It can no longer be used to expand the selection to the left (unless you go all the way and deselect the initial selection altogether and then continue in the other direction).
I find this behaviour rather weird, and difficult to get used to. It means that if, when using my mouse pointer from left to right to select a text string, I overshoot and want to shrink the selection by one or two characters, I first must expand the selection by hitting shift-Right once, and then I can use shift-Left to shrink the selection.
Having to expand a selection first in order to shrink it is rather, shall we say, counterintuitive.
But I suppose that Apple’s engineers thought long and hard about this one and decided that this was the best possible compromise. (I do wonder what they call it, because it’s obviously neither an anchored selection nor an unanchored one. Is it a “smart unanchored” selection? It depends on your definition of “smart,” I suppose…)
My real problem, however, is with the fact that this behaviour is not applied consistently throughout Apple’s Mac OS X applications. For example, I would argue that, when you select an item in the Finder and make its name editable, you effectively open a small text editor, where you can use both the mouse and the keyboard to create selections of words or characters.
Shouldn’t these text selections work the same way as in Pages, TextEdit, etc.? But they don’t. Text selections in file names in the Finder (and in text fields in dialog boxes) use the old anchored selection scheme, where the direction of the shrinking/expanding, either with keyboard shortcuts or with the mouse, depends on the original direction of the initial selection.
And what about selections in lists of stuff? Which logic should they follow? Why not follow the same logic as with text selections in Pages?
Take a selection in the message list in Mail, for example. Let’s say I use my mouse to click-and-drag vertically from top to bottom in order to create a selection of messages:
If the text selection logic described above for Pages was applied here too, the behaviour of the shift-Up and shift-Down shortcuts should work the same way as the behaviour of the shift-Left and shift-Right shortcuts in Pages.
I should be able to expand and shrink the selection, and the starting point of the expanding/shrinking would depend on which keyboard shortcut I use first. But that is not the case. In this situation in Mail, regardless of which keyboard shortcut I use first, Mail shrinks/expands the list from the bottom, which is the behaviour of an anchored selection:
Of course, to make matters worse, there are other contexts very similar to the message list view in Mail where the behaviour is yet again different. In iTunes, for example, if you create a continuous selection of tracks with the mouse by clicking on the first one and then shift-clicking on the last one, the behaviour of the shift-Up and shift-Down shortcuts after that follows the description provided by John Gruber for his definition of the unanchored selection, i.e. they can only be used to expand the selection from the top (shift-Up) and from the bottom (shift-Down).
On the other hand, selections of table cells in Numbers behave the same way as selections in Mail’s message list, i.e. as anchored lists.
It’s all rather frustrating, I find. And it gets even worse when you add third-party applications to the mix, which bring their own idiosyncratic ways of handling selections.
The bottom line is that, not only is the logic of the Pages behaviour described above difficult to get used to, but on top of that you shouldn’t get too accustomed to it, because it does not apply consistently to all Mac OS X applications. And it is essentially impossible to predict which behaviour will apply. You are just supposed to know that, in Pages, TextEdit, the message editor in Mail, etc. it works this way, and in text input fields, the message list in Mail and tables in Numbers it works that way, and in the track lists in iTunes it works yet another way.
Will we ever get a computing environment where all selection-related behaviours are predictable and easy to absorb and get accustomed to? By the looks of it, it won’t happen in my lifetime.