Cor­rect Cur­sor on Ac­tive El­e­ments

Every ac­tive el­e­ment must have a set cur­sor on hover. And it should be cur­sor:pointer in most cases.

By ac­tive el­e­ments I mean links, but­tons, se­lects, la­bels with check­boxes and ra­dio but­tons, and other sim­i­lar el­e­ments.

Those el­e­ments should be treated as “ac­tive” when click­ing on such el­e­ment re­sults in any ac­tion. Thereby a menu item for the cur­rent page, checked ra­dio but­ton or dis­abled but­tons or links are not ac­tive el­e­ments, so they should­n’t have any change on hover.

At first I thought it’s ob­vi­ous, but then I found out there are a lot of de­vel­op­ers who think oth­er­wise. And I did­n’t find any proper ar­gu­ments against cur­sor:pointer for ac­tive el­e­ments af­ter read­ing all their points of view.

In this ar­ti­cle I’ll tell you my ar­gu­ments at first, and then I’ll dis­cuss all the ar­gu­ments against my point of view, de­scrib­ing why those ar­gu­ments had­n’t in­cline me from it.

Ben­e­fits of us­ing cur­sor:pointer

Visual Feedback

For me the main profit from changed cur­sor is the vi­sual feed­back. Ide­ally every cus­tom el­e­ment should change its state on hover. How­ever, in real life such state could be ab­sent or would­n’t dif­fer much from the orig­i­nal state, or would hap­pen with a tran­si­tion. So there would be no feed­back, or it would be not ob­vious.

But you surely would see when the cur­sor changes —this hap­pens in­stantly and sta­ble. The click that could fol­low the mouseover would be in­tu­itive, oth­er­wise the brain would need to match the po­si­tion of the cur­sor with the el­e­ment or spot the el­e­men­t’s change and then find out if it’s a hover state over this el­e­men­t’s ac­tive area or some­thing else.

Chang­ing of the cur­sor is the most nat­ural, no­tice­able and ob­vi­ous feed­back you could eas­ily add to any el­e­ment. Of course, it’s not the best vari­ant, but it’s cheap and easy. If you could add a dis­tinct vi­sual state on hover, then it would be even better.

Delim­i­ta­tion of the ac­tive area

There are a lot of cases when you should hint to the users that they could click al­ready. You could of­ten want to in­crease the click­able area of dif­fer­ent el­e­ments, like for small icons or for menu items placed near the win­dow edges. In those cases adding a cur­sor on hover would help users to find out when they could click on an el­ement.

In some cases, when there are ad­ja­cent el­e­ments, the cur­sor would­n’t be enough to tell which el­e­ment is hov­ered —in those cases you should change the vi­sual state of those el­e­ments.

Any­way, if you’d hint users when to use any spe­cific ac­tive el­e­ment, users would know it and it would be eas­ier for them to use the UI next time —they’d need to aim with less pre­ci­sion, be­cause they’d know that ac­tive area of an el­e­ment could be big­ger than it can be seen. And when they’d move the cur­sor they could click right at the mo­ment the cur­sor would change. Oth­er­wise, if an el­e­ment don’t change its cur­sor on hover, the users would need to aim care­fully to hit the area of a small el­e­ment like icon or checkbox.

And I could ar­gue if some­one would say the ac­tive area of an el­e­ment should be as big as its vi­sual rep­re­sen­ta­tion, but I’ll keep my ar­gu­ments on this topic for an­other ar­ticle.

Argu­ments against chang­ing the cursor

I re­ally did try, but had­n’t find any proper ar­gu­ments against chang­ing the cur­sor over the ac­tive el­e­ments. Most of those ar­gu­ments can be de­scribed as “Don’t break users’ habits!”

But you can’t treat the pres­ence of habits as an ar­gu­ment. This means there was one of the pos­si­ble so­lu­tions and it was ei­ther the only one there, ei­ther it was the best at the mo­ment. The habit should be treated in its con­text, and in con­text of what would hap­pen if we’d brake it. Would it be de­struc­tive in some way, or it would be just a mat­ter of mi­nor users’ dis­comfort?

An­other fact is that not all of the habits are good. If we’d al­ways stay with the users’ de­sires, the progress would stop. Of­ten users be­come used to the things that only hin­der them. A clear ex­am­ple of such bad habit are la­bels for check­boxes and ra­dio but­tons. Lazy de­vel­op­ers did­n’t bind them to­gether for years, so users of­ten don’t know what the la­bels could be ac­tu­ally clicked, so they spend their time and ef­forts try­ing to hit those lit­tle ar­eas of those lit­tle con­trols even if the la­bels are click­able too. It’s a great ex­am­ple why you should not only bind the in­puts with la­bels, but also tell users about it with all pos­si­ble ways.

We could di­vide the “habits ar­gu­ments” into dif­fer­ent cat­e­gories. I’d try to an­swer the most fre­quently used ar­gu­ments against the chang­ing of the cur­sor on hover.

The cur­sor does­n’t change in users’ OS”

In OS the most used cur­sor is just an ar­row. It does­n’t change over most of the sys­tem con­trols like but­tons. How­ever, the ques­tion is “Is this re­ally good?” Is it fa­mil­iar? Yes. But is it us­able and could it be bet­ter? I of­ten see how some desk­top app is not us­able be­cause I need to guess where to click —there are no signs of ac­tive areas.

When we are talk­ing about desk­top we should also talk about games too. Un­like apps, games of­ten have cus­tom cur­sors that are changed over dif­fer­ent UI el­e­ments. In com­par­i­son with mod­ern games most of the web apps feel like the old games with pixel-hunt­ing —you have to guess where to click and where to hover in or­der to do some­thing. How­ever, re­cently the web apps tend to use more cur­sors for dif­fer­ent ac­tions like drag-n-drop or re­size. But why then use the de­fault cur­sor for but­tons? cur­sor:pointer would fit great there. And when we’d look at the check­boxes and ra­dio but­tons, then there should be not only a dis­tinct vi­sual hover state like changed back­ground, but you should­n’t for­get to set the cur­sor:de­fault for them —that’s the cur­sor the desk­top apps mostly use to se­lect some­thing. But if se­lect­ing the check­box or ra­dio but­ton re­sults in a UI change like ex­pand­ing the ac­cor­dion’s sec­tion, then the best cur­sor would be a pointer one —telling some­thing would hap­pen af­ter you’d click.

Web apps are not the same as desk­top apps, there are a lot of new pat­terns and UI el­e­ments there, so it’s time to think again and de­cide which habits to forget.

Ah, that’s an­other of­ten used ar­gu­ment. When there were no web apps, there were only linked tex­tual doc­u­ments. The apps mostly did­n’t have such links, so in browsers, to tell users what the HTML <a> is, there ap­peared un­der­line, blue color and a pointer cur­sor. And as all the but­tons and in­puts were sys­tem con­trols, they in­her­ited the de­fault be­hav­ior with the de­fault cursor.

Years passed and sites be­come more com­plex and UI-rich, de­sign­ers cre­ated new con­trols and they of­ten were just the links dis­guised as but­tons and other el­e­ments. And in most cases no­body re­moved the links’ cur­sors. So if you’d look at the mod­ern sites, most cus­tom but­tons would be ac­tu­ally links and would have cur­sor:pointer there.

In fact, you should for­get the “pointer is for links” thing a long ago.

Well, yeah —links are not but­tons, and but­tons are not links. But that does­n’t mean the be­hav­ior of hover for links and but­tons should differ.

No­body would ex­pect an abil­ity to open some­thing in a new tab from the but­ton. In each case both the links and the but­tons would have their con­text where users could ei­ther await the link’s be­hav­ior, ei­ther they would just use the con­trol they have. And it re­ally does­n’t mat­ter which cur­sor the users would see —if users would see a cur­sor in a links’ con­text, they would treat it as a link. But if users won’t ex­pect a link, the but­ton un­der­neath would be ok. If users would like to at­tach a file, they won’t need the link’s be­hav­ior. If users would like to send a form, they would just do it, even if there’d be a cur­sor:pointer on it, the users won’t go away and won’t try to open it in a new win­dow —they al­ready know how to use search forms. The only place when the users would be con­fused —if you’d do it re­verse: make a but­ton look like a link —be blue and un­der­lined.

Fur­ther more —there are al­ready a lot of links that don’t look like ones and other el­e­ments that are dis­guised as links. Dif­fer­ent drop­down han­dles, fil­ters, cuts, clos­ing icons, “can­cel” links —a lot of sites have a lot of el­e­ments us­ing dif­fer­ent tags in HTML for them and hav­ing this cur­sor:pointer. Why would then sim­ple but­tons or se­lects have de­fault cur­sor in­stead of the one all other con­trols have?

There is a great ex­am­ple from one com­pa­ny’s service:

Active areas example

You could try to guess which marked el­e­ments are links, which are not; which have cur­sor:pointer, which don’t. What would hap­pen when you’ll hover or click any of those el­e­ments? You can think for a while, and I’ll give you an an­swer later.

If you’d say straight­for­wardly “only every­thing that have href must have a cur­sor” then a lot of con­fus­ing things could ap­pear. For ex­am­ple, if there would be one el­e­ment vi­su­ally, but with dif­fer­ent tags un­der­neath (like boot­strap’s but­tons are), then it would be strange and con­fus­ing if there’d be a dif­fer­ence be­tween the but­ton made of <a> and <but­ton>. So, I hope every­one would agree that the cur­sor over every such el­e­ment should be con­sis­tent. And If you’d make the de­fault one, then it would be­come re­ally con­fus­ing, ’cause there could be a dis­abled state for this but­ton and you would need to spot the change of the but­ton’s back­ground in or­der to know could it be pressed or no. And then if you’d re­move the cur­sor:pointer from an ac­tual link it won’t be any bet­ter, so the only proper way is to have cur­sor:pointer in both cases.

We could find a lot of ex­am­ples with but­tons, links and their states would con­flict with each other and the over­all UX. Mak­ing the cur­sor:pointer to mark only ac­tion­able el­e­ments makes sense and won’t cre­ate any con­flicts other than slight dis­com­fort for some persons.

And let’s get back to one strange service:

Active areas example

So, what’s there?

  1. It’s the post’s perma­link. Ok, it’s an ac­tual link, there is an un­der­line and a pointer on hover.

  2. Hey, it’s not a link, it’s just a text, not click­able at all.

  3. That’s pseudo-link, there is no ac­tual link, but there is a hover state as the one on perma­link: un­der­line and pointer. Click­ing here calls a drop­down to appear.

  4. An­other con­trol that be­haves like link (changes color on hover and gets cur­sor:pointer), but there is no ac­tual link. Again, drop­down on click.

  5. This icon is not a link and click­ing on it does noth­ing, while the other parts of the snip­pet —header and pic­ture —are links.

  6. There are two links: user­pic and user­name. They’re not con­nected and have their own hov­ers: pointer and an un­der­line for username.

  7. It’s a pseudo-link, no href seen. And the un­der­line on hover and pointer.

  8. Oh, a but­ton! A cus­tom but­ton. But what’t that? No pointer on hover! And even more —hover brings the drop­down, I feel like on a mine­field there.

  9. So, the but­ton was treated as a “sys­tem” el­e­ment, but what’s with check­box? It and its la­bel have cur­sor:pointer. Wow.

So, what could I say? There is no even slight con­sis­tency and a lot of other UI mis­takes. But hey, there is no cur­sor:pointer on a but­ton! I won­der which ex­cuses the de­vel­oper have for this.

BTW it’s very in­ter­est­ing to look at dif­fer­ent ser­vices in the search for con­sis­tency, al­most no one is per­fect, so you could of­ten find things to think about and to crit­i­cise on.

But the specs say…”

Se­lenIT brings an­other ar­gu­ment (in Russ­ian): both the CSS2.1 spec and the CSS3 Ba­sic UI clearly state that “the cur­sor is a pointer that in­di­cates a link”. He also gives a link to a Gérard Tal­bot’s mes­sage, where he de­clines a change to one of the CSS2.1 tests. How­ever, it could­n’t be an ar­gu­ment for this is­sue —the con­text of this mes­sage is a test for spec, and if spec says some­thing, then the test should cover only this.

In specs it is only said the pointer is sup­posed to be used for links, but it don’t im­ply you can’t use it for any­thing other than link. It states the de­fault use of such cur­sor, noth­ing more. More­over, I think this part in specs should be changed to some­thing like “The cur­sor is a pointer that in­di­cates an el­e­ment that can be clicked” to re­flect mod­ern state of the web —’cause the cur­rent state­ment is come at least from the year 1997 and a lot of things did hap­pen since then.


Here is an­other, dif­fer­ent from habit ones, ar­gu­ment. If there would be a lot of ac­tion­able el­e­ments, they say, the cur­sor would blink a lot when you’d move it here and there.

But that’s not a proper ar­gu­ment, it’s a pointer for one of an­other problems:

  1. Ac­tive el­e­ments could be placed not that close one to an­other. In that case it would be harder for users to hit those el­e­ments and there would be symp­to­matic flick­er­ing when you’d move the cur­sor from one such el­e­ment to an­other. Ide­ally, those el­e­ments should have con­tin­u­ous ac­tive ar­eas. And to de­limit dif­fer­ent el­e­ments in that case you should use the vi­sual hover like chang­ing back­ground and not the cur­sor­less gaps.

  2. An­other prob­lem —clut­tered in­ter­face. If you’d have whole page cov­ered in ac­tive el­e­ments, then —yeah —the cur­sor would change a lot (how­ever, it al­ready changes a lot when you hover over text or other sta­tic el­e­ments). When you have a lot of ac­tive ar­eas, it could be that you need to sim­plify some­thing there.


In ideal sit­u­a­tion every ac­tive el­e­ment should have a dis­tinct vi­sual hover state. But even with such state it won’t hurt to add a cur­sor:pointer —it would only add clar­ity and would re­move pos­si­ble UI con­flicts. And if you can’t find how to make a vi­sual state on hover, adding pointer would be enough for most cases (how­ever, if you’re work­ing with a de­signer, it would be bet­ter to ask them to give you a cor­rect vi­sual hover state).

And there are just no other ar­gu­ments against cur­sor over ac­tive el­e­ments than user habits. And there would be more happy users than those who moan.

How­ever, if you have any other ar­gu­ments I did­n’t cover —I would like to hear them. If you know of any A/​B-test­ing with dif­fer­ent cur­sors —it would be very cool to look at the re­sults of those.

Any­way, I hope now this topic is ob­vi­ous and you would go and add the cur­sor:pointer to any­where on you page where it is needed.

  • Chris Coy­er’s snip­pet on adding pointer cur­sor

    Ex­cept for the snip­pet it­self, in the com­ments there are all the same ar­gu­ments on habits and points of view with­out ar­gu­ments at all.

  • Dmitry Fadeyev’s ar­ti­cle on cur­sor’s af­for­dance

    In this ar­ti­cle Dmitry comes with this state­ment: “If the cur­sor type is wrong, spec­ify it us­ing the CSS cur­sor prop­erty” and gives as an ex­am­ple cus­tom but­tons and in­put place­holders.

  • Vadim Ma­keev’s slides (in Russ­ian)

    Nice slides on us­ing the right el­e­ments for right pur­poses and all those things, how­ever Vadim says you should­n’t make a pointer cur­sor for but­tons and I dis­agree there. Hope he’ll make up his mind af­ter this ar­ticle.