Mac OS X 10.5 (Leopard): Misleading new link highlighting behaviour
Posted by Pierre Igot in: MacintoshNovember 23rd, 2007 • 10:51 am
There is a new highlighting behaviour in Mac OS X 10.5 that occurs whenever you control-click (or right-click) on a link. Look at what happens, for example, when I control-click on a URL in a e-mail message in Mail:
In addition to bringing up the expected contextual menu, Mac OS X actually also chooses to highlight the link that I am clicking on. But instead of highlighting the entire link, it only highlights the “word” on which I have clicked. A word, here, seems to be defined by “anything between two punctuation signs,” including spaces, periods, etc.
I can understand the desire to highlight something in order to indicate to the user what his mouse click and the commands that this click brings up actually apply to. But if that’s the intention, why does it only highlight a portion of the link?
Surely it is quite obvious that the commands in the contextual menu apply to the entire link and not just to the highlighted “word.” This creates a rather bizarre situation where you have a command such as “Copy Link” that applies to the entire link but it actually looks like you are only going to copy the “word” that is highlighted. In other words, what is highlighted and what is selected are two different things. Not good!
For the record, the same thing happens in Mail, Safari, etc., so it’s clearly something that Apple implemented in Mac OS X itself. It also occurs both for links where the text of the link is the same as the actual URL of the link (as in the example above) and for links where the text of the link is not a URL, but a regular phrase. And the punctuation signs that are treated as separators between “words” can also become “words” themselves and be highlighted by themselves, if your mouse click falls exactly between words or on a punctuation sign.
This can lead to truly bizarre situations where control-clicking on a text link actually highlights the space between two words:
I really do not see how this can be anything other than misleading. It’s not like there are commands in the contextual menu that apply to the actual text that is highlighted (a single space?) as opposed to the underlying link (although that could in theory be useful, since sometimes you want to copy the text of a link rather than the value of the underlying URL).
In fact, here is the probable source of this strange new behaviour. When you control-click on a word that is not a link, then things start making more sense:
Mac OS X automatically highlights the whole word and shows menu commands that can be applied to this word, such as “
,” “ ,” and “ .” And if the control-click falls on the space between two words, then Mac OS X highlights the space and just offers one command, “ ,” plus some application-specific command such as “ ” (in Mail) and “ ” (in Safari). Presumably searching for a space in Google or in the dictionary is not likely to produce mind-opening results.(Now here’s an efficient way to enter a space if I ever saw one: control-click on an existing space, copy it, then place your insertion point in the destination and control-click to bring up the “
” command. Four mouse clicks and movements just to insert a space. Wow!)So that’s probably what happened: Apple introduced this new functionality for applying commands such as “
” and “ ” to regular text, and somehow forgot to check what the behaviour would be when the “text” in question would actually be part of a link. Unfortunately, when the text is part of a link, control-clicking brings up a completely different contextual menu, which no longer contains commands such as such as “ ,” “ ,” and “ .” And so the highlighting behaviour becomes wrong and actually misleading.If Apple really wanted to give the user some feedback on what is selected by his control-clicking on links, it would have been more appropriate to put some blue halo around the whole link or something like that. But it doesn’t look like they bothered to design a different behaviour when control-clicking on “words” that are part of a link, and I must say that it makes their work look rather amateurish and unpolished.
November 23rd, 2007 at Nov 23, 07 | 3:46 pm
I am running Tiger 10.4.11 and it now works the same, so it was a change Apple made recently as 10.4.10 didn’t work that way. although you used to have to double click the word and then right click to get the search contextual menu. Now simple right clicking a word brings the contextual menu. if you right click on a space the only option for me is copy text. I notice the change right away on the right clicking of links but kind of liked the idea of the highlighting so I knew I was right clicking on the link I wanted.
November 23rd, 2007 at Nov 23, 07 | 4:36 pm
This highlight behavior occurs in Safari and Mail in Mac OS X 10.4.11 as well.
November 23rd, 2007 at Nov 23, 07 | 5:02 pm
Interesting. That probably means that it’s a change that’s part of the Safari 3.0 architecture and underlying engine used for rendering content, which is obviously used by a variety of applications. It is probably part of the same engine that also handles the automatic detection of addresses in textual content. Does the automatic detection of addresses also work in Mac OS X 10.4.11?
(You can check this by hovering over a name in the body of an e-mail message in Mail that is a name that also appears in your Address Book. For example, if I send you an e-mail and I sign it “Pierre Igot” and you have an entry for Pierre Igot in your Address Book, then automatically when you hover over “Pierre Igot” at the bottom of my e-mail, it becomes a link with a contextual menu, even though it’s just plain text in the e-mail message itself. This might be a Mail 3-specific feature, though.)
November 24th, 2007 at Nov 24, 07 | 6:39 am
Looks like a WebKit bug. Seems to fit the description of this one:
http://bugs.webkit.org/show_bug.cgi?id=15279
At least it’s marked as “in radar”, although it doesn’t appear to be labeled as a regression.
November 24th, 2007 at Nov 24, 07 | 11:23 am
Yes, sounds pretty much like the same thing. Thanks for the link.
November 25th, 2007 at Nov 25, 07 | 6:57 pm
I suppose we can’t flunk opinion. I have a couple of thoughts where this behavior makes sense to me and could be quite useful.
First, IMO control-clicking should only highlight specifically what you are pointing at. That makes it consistent. Of course it’s another argument about whether we are clicking just a word or a whole link. I think we should lean toward “word” because quite often the linked text has no correlation to the actual URL.
Second, I would like to see another option in the contextual menu when control-clicking on a link. There are many times I would like to only select a specific word in a link and do a Google search on it. This current behavior of selecting when control-clicking would be wonderful for me if I now had a Google search option too.
If it’s a bug I’d like someone to take advantage of it and add that Google search! :)
November 25th, 2007 at Nov 25, 07 | 10:20 pm
I am not saying that there are no situations where it would be convenient to have the automatic selection of the word under the mouse pointer even if it’s part of a link. In fact I quite frequently encounter situations where I want to select the text of a link without following the link, for which I have to use a clumsy workaround such as starting the selection a few chars before or after the link text.
But the reality is that having a disconnect between what is highlighted and what is selected sets a dangerous precedent.
Now, if in this particular case the contextual menu did include commands such as “Search in Google” and “Look up in dictionary” as well, then you could probably argue that it’s a precedent worth setting, that maybe Apple is onto something with this “dual selection” type of thing—although it wouldn’t solve the problem of wanting to select more than one word in the link text.
But the reality is that, at this point, the menu does not contain commands that apply to the selected word only, which makes my description of it as a bug more than just an opinion :).