a[href], input[type='submit'], input[type='image'], label[for], select, button, .pointer {
cursor: pointer;
}
Some elements that are clickable mysteriously don’t trigger a pointer cursor in browsers. This fixes that, and provides a default class “pointer” for applying it to other clickable things as needed.
I generally dislike having the pointer on a button and such, it just feels… wrong :o.
I’m going to completely disagree here, not having the pointer on all buttons and links is horrible for usability
Average User won’t notice the difference, but you’re right. Desktop Applications don’t have a pointer on Buttons.
“It’s all about Affordance. Buttons have a high affordance which visually suggest how they can be used. The hand pointer is used when affordance is lower to provide an indication of how to interact with that item.”
So where in the CSS do you place this? I actually think it’s genius. Not too many people know that when a link is a different color (minus the underline) it’s clickable.
Just stumbled upon this – could be used like so as well:
@DanEden I assume that would only catch elements where the ��onclick” attribute it explicitly set? Which is a shame, because all good JavaScripters (in my opinion) use attachEvent or something similar to set onclick events.
Chris, but doesn’t this piece of advice contradict the CSS spec, which (both CSS 2.1 Recommendation and CSS3 Basic UI LCWD) consistently say that
cursor: pointer
“is a pointer that indicates a link” (not “something that is clickable”)? Gérard Talbot, one of the W3C CSS 2.1 Test Suite authors, even writes in the W3C mailing list:So is he completely wrong or changing cursor from the shape that users may have got used to in certain contexts really may have not just advantages, but also drawbacks? And do these advantages justify the formal violation of the CSS spec?
I wonder if replacing
a[href]
bya:link
wouldn’t be better for performances. I heard attribute selectors are by far the worst selectors when talking about speed.Good =)
This is a classic design anti-pattern. The arrogance of a designers/developer to conclude that operating system and browser vendors are doing it wrong, and to challenge the basic assumptions of web users by altering core interface behaviours and idioms they’ve become accustomed to.
The pointer/hand cursor, is for links only. I like to clarify that further with respect to the web and suggest that such cursors should only be applied to links recognised by the browser, which is pretty much href’s only. If I can’t middle-click it and open it in a new tab, then it shouldn’t have a pointer cursor. The only exception I can think of is when the buttons it’s used on aren’t obvious buttons (low affordance) – though that’s normally a result of bad design.
I’d change
label[for]
tolabel
as per<label><input type=radio/>label text</label>
.Anyway if anybody needs s whole list of cursors, it can be found here with examples: Change cursor by CSS
In Firefox 22 a cursor:not-allowed; on disabled input fields (e.g. in calculation forms for frame sizes or what ever) only shows up on the edges of the field.
In Version 21 it still worked properly.
In IE7-9 the cursor shows up only on the area of the value instead of the whole input field.
What I want to say is:
All the discussions about whether one should use cursor:pointer; on button elements or not is inane as long as browser architects follow their egozentric thoughts and not one browser on the planet is consistent and follows all W3C advices.
Cheers,
noRiddle
We have no idea how it work. To short explanation & no sample.
learn CSS first.