The situation: you click down on a link and you suddenly realize you didn’t want to click that link. So before you release the mouse button, you move the cursor away from the link.
This is what I am calling “aborting” a link. Years ago now, I remember seeing somebody’s demo where they found some weird combination of CSS which made it so you couldn’t abort from a link. It’s been on my to-research list for a long time, and I just started to get around to it. I wasn’t able to dig anything up, or find much written about it elsewhere. I have a feeling that it was more of a weird old browser bug, and not something easily replicate-able in the modern browsers I am using now.
This idea of aborting links is pretty interesting though. As it turns out, different browsers have pretty different ways of handling it. Let’s take a look.
Firefox 3.5.6
In Firefox, you can click anywhere inside the link and you have about a 5-pixel dragging radius before the link is aborted.
Safari 4.0.4
In Safari, if you click off the text, you can drag anywhere within the link and the link will not abort. You have to release the mouse actually outside the link for it to abort.
If you click on the text, you have about a 40-pixel radius before the link will be aborted, showing you a small link-popup.
Chrome 4.0.249.30
No matter where you click in Chrome, you have about a 40-pixel drag radius before the link is aborted.
Opera 10.10
In Opera, if you click and drag left or right, or even diagonally, the link will not abort until you leave the confines of the link. But if you drag up or down, your link will abort in about a 5 pixels. This is for clicking off the text itself.
If you click on the text, you have about a 5-pixel radius before the link will abort. Left or right dragging will actually select text, which is unusual (in other browsers you have to click outside the link and drag around to get a text selection).
IE 8.0.6
IE has a consistent 5-pixel radius to abort no matter where you click.
So?
So – nothing. It’s just kind of interesting how different browsers, even browsers that use the same rendering engine, handle aborting links differently. This is definitely something they thought about while creating the browser, and all came to different conclusions on how it should be handled.
This concept applies to anything with a click or touch surface. For example, the iPhone allows you to abort the pressing of an icon / link, but simply moving your finger away from that area.
For the record, the demo page used in this research is here.
If you wanted to be a real bastard…
It is important the links are able to be aborted. It’s just common courtesy, to allow someone to back up out of a mistake before it happens. However if you really had a good reason why you needed a link to be unabortable (or you were a real bastard), you could redirect the page with JavaScript on the mouseDown event. Here is some jQuery:
$(function() {
$("a").mousedown(function() {
window.location = $(this).attr("href");
});
});
Don’t let the marketing team see this one. They’ll insist that you add it to every link that leads towards a sale or an ad link. Thanks Chris for another article!
Its funny because its true.
lol it could be worse…
“Can you have a user go to any link that you just hover over?”
Yea, just change the
$("a").mousedown(function() {
window.location = $(this).attr("href");
});
to
$("a").mouseover(function() {
window.location = $(this).attr("href");
});
Very interesting, not very useful tho’! :P But kudos on the research!
I second the kudos on your research. How did you test each browser? Just curious.
An interesting article … another backlink for Google.com
sometimes it’s fun being a bastard! hahaha!
some nice research, though i can’t say i’ve had to abort that often.
I too would have thought that webkit browsers would have had this wrapped up. I wonder if there are differences between versions of firefox (ie v2 vs v3) or if the OS has a bearing on this too?!
It looks like you’ve mixed up your Opera one. The picture suggests that with up/down movement you have to move to the edge, but the text says you have to move to the edge with left/right movement… Otherwise very interesting, good work.
I might start using that jQuery snippet in projects where the client is being a dick. That, and br { display:none; } just to frustrate
So you’re saying some browsers are pro-choice? ;)
You come up with the most unique browser testing ideas, I never would have thought to test this out.
This comment is really off topic, so I’ll undesrtand, if you delete it. I just used some great css technic, that can solve your problem with frillies in Kailin Yong project (I would post this comment there, but it seems that I can’t).
It’s actually more use of css selectors rather than a technic (I had got a bit more complicated situation, so I developed a nice technic (I mean technic technic)).
Long story short – :before and :after :D.
I don’t agree you should always abort links!!! however sometimes you can win time to start loading things and perform AJAX calls. It can be only 50ms but however that’s a lot when you try to make your app faster!
Interesting research… this issue came up when I was working UX at Google, and the way this is handled in Gmail is worth noting. Generally you always want to give you users the ability to abort a click (especially with consequential actions such as confirming a purchase in commerce situations) however I believe the Gmail team shoots for no action taking more 180ms… and there is 30-70ms of latency waiting for ‘release’ which is accumulated through the browser, the mouse, and the human.
So they opted to make emails open on click rather than on release because the collective time saved when clicking through dozens of emails far out-weighs the less common use case of needing to abort opening an email (plus users know how to quickly get back, and how inconsequential opening the wrong email is). The decision does make Gmail feel way way snappier…
The moral… this stuff definitely matters from a user experience perspective, both allowing users to abort a click when it really matters, but also for speeding things up when that makes more sense.
Interesting! I was just playing with that in GMail and indeed it does respond on mouseDowns rather than waiting for a release. I’m sure that does add quite a bit of snappiness to a hardcore AJAXy app like that.
Nice to find out how GMail is using this !
That’s interesting! Never really noticed it till now, but yeah, that does make a lot of sense when it comes to opening email.
Interesting stuff Chris and I agree with Eire32, don’t let marketing see this one!
I LOVE the re-design by the way. It is interesting to see how you find ways to apply some of your own latest *tricks* as you go through each release —that’s just pure ‘awesome’
Me to ,I love it (re-design) The site is awesome !
Another test like this; Drag links to the tabs bar opens the link in a new tab, only IE opens in the same tab. Draging a image will open the image, dragging a image inside a link will open the link.
Firefox is the only browser which enables dragging everything (also normal text) to the tabsbar.
Damn why did i ever test this?
Interesting information & little research you tried to dig up I’ve been wondering how it was for other browsers, other than Mozilla, on how they took upon action on aborting links.
The thought came to mind when messing with my iPhone one night & i tried to avoid going into something I accidentally clicked while laying down uncomfortably. Then I went online on my Mac Mini G4 to see how Firefox reacted to clicking and moving my mouse away. Was interesting to see it take the same effect as my iPhone, in some what of a way, of course I didn’t really do any hard work/research.
But hey thanks, ya gave me more info on this + other browsers & a nice code snippet!
– MexiChriS
In Opera, the up/down dragging of the link is used to create a bookmarklet on the toolbar. Left/right don’t. Hence the difference.
Thought I was the only one that “aborted links” lol. Is that the actual term for it?
wondering how many more browser will be hitting the market & making us ( web designers ) do more work for testing/correcting rendering issues in all browsers :)