[RFC] Cursor pointer on interactive elements

[eps1lon]

We're currently applying cursor: pointer for most interactive elements (Button, Checkbox, labels of checkboxes, Slider etc).

It's well defined that this cursor indicates a link¹.

Problems arise especially for components that are mapped to host elements e.g. Checkbox for <input type="checkbox" />. The host element does not have a pointer cursor nor does its label. This is especially confusing since we use the default cursor for labels of textfields.

I'd like to hear some other opinions. Especially focusing on different kinds of elements and inconsistencies between our elements and host elements.

Some more resources outside of html:

• https://ux.stackexchange.com/a/105027/131078

¹specified in CSS3 UI

[oliviertassinari]

t's well defined that this cursor indicates a link1.
https://ux.stackexchange.com/a/105027/131078

Oh wow, it's fascinating to see how things evolve! Is it correct to assume that a majority of the websites/apps are not using cursor: pointer for the only purposes to indicate link?

On this matter, I would recommend matching as close as possible past learnings of the majority of the users, e.g. for the checkbox, I'm not sure that the majority is used to a cursor pointer, for a button, I suspect the majority to be used to a cursor pointer.

[eps1lon]

My suspicion is that at some point somebody used a div to link content and used the pointer. And everybody assumed this was an action and therefore any action should have this cursor.

Looking through vscode I can only find a pointer cursor when it actually links content e.g. a filename in the console.

If you look at the Microsoft design guidelines you find that the rationale for the pointer cursor is that links are usually hard to recognize. This doesn't apply to something like a Button in Material Design or an IconButton which has extra hover styles.

[TheRusskiy]

Having "pointer" on interactive elements makes a lot of sense to me. It feels weird without it.

[joshwooding]

On GitHub, everything seems to have cursor: pointer 😅

[eps1lon]

Having "pointer" on interactive elements makes a lot of sense to me. It feels weird without it.

In the browser I would agree. Using ubuntu + gnome I rarely see them on native UI (e.g. menubars, shortcuts)

[mbrookes]

It's well defined that this cursor indicates a link.

However the demo at the beginning of that page uses cursor: pointer on the elements used to select the pointer type to to view.

[eps1lon]

We can find dozens of contradicting examples. None of which relate to the statement you quoted. I already said that I'm aware that definition is mostly ignored. No need to make clever remarks about contradicting examples

[oliviertassinari]

What's the next step with the issue?

I have spent some time looking at the UIs of Facebook, Gmail, Twitter, Instagram, and Stripe. I have noticed a trend from

1. cursor: pointer only for links, to
2. cursor: pointer for links and buttons and
3. to cursor: pointer for any element that has a click interaction attached to it.

It seems that the trend of the internet is to progressively go from 1 to 3. The older parts of the UIs tend to follow 1, and more often 2, while the more recent UIs tend to follow 3.

On the UI kit landscape, I couldn't find any 1. and the following (from all the ones I benchmark: ~30) that uses 2. (no cursor pointer on labels checkboxes, and radios): atlaskit, smooth ui, ebay mint, bootstrap, sancho-ui and GitHub primer. The majority is on category 3.

[oliviertassinari]

I think that we should embrace the current trend of the web ecosystem, from 1 to 3. It seems that we are a bit ahead of the web, as a whole, but hopefully, in the long term, we are following what the majority of the websites and applications are doing.

I think that we can revisit it if we get more feedback from our users in this direction, until then, we can close it.

Side note: I had a look at vscode and fabric-ui of Microsoft, both seem consistent, they seem to follow 3. For instance, you would find a cursor pointer for checkboxes.

Thanks for raising the concern!

[oliviertassinari]

An update, the W3C working group discussed this topic in w3c/csswg-drafts#1936 and updated the guidelines: w3c/csswg-drafts@272dd50