Bootstrap: Remove hand-cursor on links displayed as button

[tbolon]

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,

[patrickhlauke]

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 a role="link" and have a matching [role="link"].btn-link { cursor: pointer; }

[Herst]

Wasn't it removed in 232e86d0b4e1a4ff0dc3aa4e6d75c14a54fa8ac8? Which is why there was a PR to add it back: #23995

[patrickhlauke]

@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 have cursor: pointer;

[patrickhlauke]

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]

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]

no, be guided by the browser default for the specific situation...submit buttons by default don't get pointer (hand) either

[tbolon]

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) ?

[Herst]

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]

BTW, wasn't there also some discussion advising against styling based on anything but classes whenever possible?

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").

I don't remember what the reason was, hopefully something other than performance.

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]

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]

How do you want to proceed @patrickhlauke?

[patrickhlauke]

@mdo going to aim for a PR soon (not sure if in time for beta 2 though)

[EugenMayer]

/ranton
What a horrible design decision based on an article comparing desktop applications with unified styling by the OS with 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]

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]

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]

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).

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]

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]

@tmorehouse

What about <a href="#" class=".btn .btn-primary"> which could be used to trigger a dropdown menu or popup or modal?

if your link triggers in-page javascript, rather than navigating somewhere, it should have role="button"

[patrickhlauke]

for what it's worth, i'm actually now leaning (personally) towards just adding cursor:pointer to 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]

For me, I just right click and see if I have an option to open in a new tab/window