Repository navigation
Remove hand-cursor on links displayed as button #24156
Description
As explained quite clearly on this article, hand (pointer) cursor should be limited to links on text and images.
The rule seems to be: for a button, there is no need to use a pointer cursor. for a text link, a pointer cursor should be used.
Currently, the underlying element is not altered: if you render a classic link as a button (<a> with class="btn") the cursor is still a hand cursor.
For example, in the documentation for the first button. For this button only, the cursor is a pointer.
Also note that the same is true for button elements rendered as links (<button> with class="btn-link"). The link should be rendered with a hand cursor. See this example on the doc.
A naïve implementation could be:
.btn-link { cursor: pointer; }
a.btn { cursor: default; }
If the solution is as simple as this, I can submit a PR.
Regards,
Activity
patrickhlauke commentedon Sep 28, 2017
if a link still acts as a link, despite looking like a button visually, it should keep its default cursor. the only way out of that dychotomy would be something like
[role="button"].btn { cursor: default; }. similarly, for buttons styled as links (which I personally think is an abomination), we should probably suggest that those, if they indeed act like a link, should be given arole="link"and have a matching[role="link"].btn-link { cursor: pointer; }Herst commentedon Sep 28, 2017
Wasn't it removed in 232e86d? Which is why there was a PR to add it back: #23995
patrickhlauke commentedon Sep 28, 2017
@Herst these are the two sides of the same argument unfortunately. what really counts is author intent / actual functionality. i.e., if something acts as a button (triggers in-page functionality), it should have
cursor: default;. if it acts as a link (navigates to a different page, or to a section within the same page), it should havecursor: pointer;patrickhlauke commentedon Sep 28, 2017
I'll take this on with the above suggested
[role="..."]based selectors (and matching change in doc)...that should hopefully satisfy both sides of the debate.Herst commentedon Sep 28, 2017
I have links styled as buttons and proper buttons on my page and I got the feedback from a tester that the cursors are inconsistent. But this was coming from a more technically-oriented person so I attached less importance to it (as opposed to #23853).
The differentiation in-page state change vs. scroll/page-switch largely makes sense IMHO, it could also be added that latter often also allows opening in a new tab (e.g. through a middle-click or the context menu); but what about submit buttons? Always a hand cursor if the page is supposed to be truly submitted?
patrickhlauke commentedon Sep 28, 2017
no, be guided by the browser default for the specific situation...submit buttons by default don't get pointer (hand) either
tbolon commentedon Sep 28, 2017
That is an interesting discussion. Reading the original post comments also raise a number of valid concerns.
The fact that a link/button can be altered to act as a button/link make any assumption irrelevant. So the idea of a "role" attribute could allow a developer to force a definitive behavior.
But should the actual default remains ? Or be based on apparence (btn-link=pointer, btn=default) instead of html element (
<a>=pointer,<button>=default) ?patrickhlauke commentedon Sep 28, 2017
note that this isn't just an "idea". it's an actual HTML attribute, which is supported by assistive technologies.
it should be based on intent. you have "call to action" type links which visually look like a button, but are links, so they really need the hand cursor. conversely, an author my choose to use
btn-link(to make a button appear similar to links adjacent to it) but it actually triggers functionality instead of acting like a real link. there, it should have the default cursor.Herst commentedon Sep 28, 2017
Some older discussion can be also found at #21812 and #17542 (necolas/normalize.css#379).
BTW, wasn't there also some discussion advising against styling based on anything but classes whenever possible? I don't remember what the reason was, hopefully something other than performance.
patrickhlauke commentedon Sep 28, 2017
In this case, it's not possible to rely purely on class, as the cursor needs to match the intent, and the classes here can be applied for different reasons (e.g. "it's still a link, it just visually looks like a button" vs "i'm using a link, but it acts as a button").
From memory, the idea was to uncouple styling from underlying markup, so the classes would "just work" even if authors applied them to structures other than those in the bootstrap docs/examples.
gijsbotje commentedon Sep 28, 2017
i watched this talk a few weeks ago, clarified a lot for me https://www.youtube.com/watch?v=eo4ksG-DLso
if i remember correctly she says exactly what @patrickhlauke is saying
mdo commentedon Oct 18, 2017
How do you want to proceed @patrickhlauke?
patrickhlauke commentedon Oct 19, 2017
@mdo going to aim for a PR soon (not sure if in time for beta 2 though)
EugenMayer commentedon Oct 24, 2017
/ranton
What a horrible design decision based on an article comparing
desktop applications with unified styling by the OSwith the browser, having a different visual display of buttons on every single page.Beside that, historically browser come from displaying content, not from being the "application windows" they are going to be used more and more - while desktop applications have exactly the inverse history, they are used as applications only and beside some widgets, they only do exactly that.
The hand cursor was one of this indicators in the web, even for experts, to see if, out of all the thousand items, one item is interactive or not, since you simply cannot guess in the web. Buttons look flat, non flat whatever, colored, with background, transparent and beside ALL that, placed on every possible place possible.
You find call to action buttons on every position in the coordinate system when you are looking at the browser. The article then compares that with a Desktop App-Menu which is placed on the top every single time and does look the same for every single application.
Its repeating again and again, some UX designer forces to invent something new, so muuuch simpler and sleeker and "teaching" other "people in the world" that this will be simpler. Paddling back in the end, since it was nothing more then then a made up invention...much rather just a change for the sake of a change... to "see any kind of progress" without having any kind of useful addition at all.
All that fits perfectly for this PR, all it does is harm without adding any more convenience, without removing any overhead or bloat or being faster.
At least people who really care like http://www.material-ui.com/#/components/flat-button do not just jump on a bangwagon of "i have something new here" and "new is better, always".
/rantoff
And yes of course, we added it back again, wont be a surprise for a lot more people using bootstrap for web-applications.
tmorehouse commentedon Nov 2, 2017
What about
<a href="#" class=".btn .btn-primary">which could be used to trigger a dropdown menu or popup or modal? (i.e. has a click/keypress handler to open the target element, and not page navigation). Should the cursor be set as pointer or default?EugenMayer commentedon Nov 2, 2017
If you use .btn, it should be clickable thus a cursor. If you use .btn and trigger it on "on hover" you might reconsider both, the styling and the idea it is a button - but still arguable that it could be seen as a button of course.
In you case, if the interaction is already triggered on hover, no need to add the cursor probably ( but i would ) - if you have to click to trigger the drop down, the hand cursor should be mandatory IMHO
Herst commentedon Nov 2, 2017
Or open accordion panes for that matter. Good question, I guess it does not act act like a classical hyperlink or link pointing to an anchor, i.e. it can't be shared or opened in a new tab so I guess some might argue that it shouldn't have a cursor for that matter and that the button styling alone should make it enough of a signifier.
SelenIT commentedon Nov 23, 2017
I'd say that
<a href="#" ...>could not be used for anything other than returning to the top of the page. Especially in late 2017, when we have things like<details>+<summary>for accordion-like things, with very decent native browser support and good polyfills for old browsers. Doing so basically means that the developer got stuck somewhere in 2003 and still tries to work around the limitations of HTML4 (or even 3.2). There is completely no need to do so now — it's just time to learn HTML. The modern HTML is really awesome! :)Also, removing pointer cursor from links (regardless their appearance) is a far worse usability problem than adding it to clickable things that are not links. If I were the validator, I'd mark the latter as a warning, but the former as an error.
Regarding the "cursor inconsistency" problem between visually similar, but functionally different elements, I'd say that first of all it just indicates the deeper underlying problem of such UI — the fact that these different elements were made look similar. Probably it would be better to rethink the whole UI in this case and make such elements more clearly distinct, than try to further unify the by changing their cursor. But this needs per-case analysis and probably there would be no "silver bullet" solution for all cases, some trade-offs may be inevitable, and in that case the pointer cursor for the non-link element would be the lesser evil.
patrickhlauke commentedon Nov 23, 2017
@tmorehouse
if your link triggers in-page javascript, rather than navigating somewhere, it should have
role="button"patrickhlauke commentedon Nov 23, 2017
for what it's worth, i'm actually now leaning (personally) towards just adding
cursor:pointerto links and buttons, rather than trying to special-case "only link-like links/buttons that somehow act as links should use that, all others get the default". as much as i sympathise with the original "buttons shouldn't use the pointer cursor" article, i really don't think users are so utterly confused by the practice...tmorehouse commentedon Dec 8, 2017
For me, I just right click and see if I have an option to open in a new tab/window
Opinionated: reintroduce `cursor:pointer`
merge after v4-beta3 release
yesuus11 commentedon Feb 4, 2022