[css-ui-4] Change the pointer cursor to indicate any interactive element.

[kizu]

For years and years the definition of the pointer cursor in specs did not change:

'pointer'
The cursor is a pointer that indicates a link.

But that definition is clearly outdated: today (and for years) this value is used by designers and developers not only for the “links” but for any other interactive element that did not have any other cursor defined for them, for example, for buttons. And there are a lot of new interactive elements in the modern web that are often somewhere between links and buttons.

For some reason, I often find articles in support for this legacy definition, but I yet to see any objective argument on why it should be like that. I myself wrote an article with most of my arguments in January 2013.

I propose to change this definition to something like that:

'pointer'
The cursor is a pointer that indicates an interactive element, clicking or tapping on which would result in any action (for example links and buttons).

I understand that that is a somewhat controversial topic, but if you'd look at the websites in the real world, you would see that probably most of them use the pointer for buttons. And its unlikely they would change it, so it would make sense for the specification to change in favor of a better definition that would make the web more accessible.

[frivoal]

This seems reasonable to me. I'll run it by the WG.

[CyberAP]

You give valid arguments in your post why it's ok to use pointer for interactive elements, but why it should be a standard for every single site and every interactive element?
I see 3 main negative side-effects of that change:

1. Fixing problems with a cursor won't work on devices that don't have any cursor;
2. It won't encourage to redesign an element to offer a better experience;
3. Using default cursor on interactive elements would be considered a bad practice (while it might not cause any issues).

This seems to me as a 'dirty hack' to ignore actual problems caused by poor design: lack of affordance or false affordance (appearance doesn't express the behavior), element misuse. These are the issues that should be addressed in the first place. Cursor is just a side-effect.

The single most common problem I encounter on almost any site is when there's a content that looks like it has a link (image, text with underline), but it actually has none, is also provided with a pointer cursor on hover, which makes you think you can copy it or open on a new page. That always leads to frustration and you implicitly encourage them to continue doing that.

With that said, I don't really mind a common cursor for every interactive element, but it should be different from the link cursor to exclude any misinterpretations. For example a hand with an arrow for links (similar to current alias cursor).

[kizu]

@CyberAP Re: your “negative side-effects”:

1. Devices that don't have cursor… they don't have cursor. That's the issue specific to those devices that have cursor. Saying that improving things for those devices is somehow bad is really strange for me. Like, should we then remove the cursor property altogether? Of course not.

2. I don't agree. As you said: there are other devices beyond desktop. Changing the cursor for desktop won't do anything for those devices, so the problems of bad states would still be there on those devices, thus, encouraging devs to fix them. And, again, the more distinctive the change of state is on hover, the better. The cursor change is uniform and instant, people would react to it faster than to any possible custom state for a custom element.

3. I'm all for the default cursor on interactive elements to be considered bad practice. Because it is. Yes, please. You saying it not causing any issues it just plain wrong.

The problems you're talking about have nothing to do with cursor. Yes, those are valid problems, yes, they are serious, but they should be solved alongside the cursor problem and not instead of it.

[AmeliaBR]

This comes down to a change of definition to reflect reality better, and I am all for it.

Personally, I wouldn't mind if browsers actually made pointer cursor the default for buttons. But that's a much trickier issue, since it would be changing well-established defaults. However, that's not what @kizu is suggesting here, and discussion of that possibility shouldn't derail the simple suggestion.

[adamsilver]

By interactive element, do you mean:

• whitespace (right click open context menu)
• select box (which in my experience is never given the pointer)
• labels
• checkboxes
• radio buttons
• text (I can select text to copy/drag)
• file inputs
• textareas/text inputs - clicking on them lets me type into them
• images (drag, right click save)
• etc

If the definition is changed as suggested then the cursor will/should be permanently set to pointer, diminishing its meaning and usefulness.

[kizu]

@adamsilver I'm not sure why you have chosen this passive aggressive tone which can easily derail the conversation. Try not to do this.

That said, if the “interactive element” would be introduced, then its definition should be added somewhere in the specs too. However, there is a chance that people from the csswg could reformulate this in a different manner, in a way that would be clearer and more understandable. The example in my proposal is just an example, a draft. Not the final version.

So, if you'd like to be constructive, you could try to think about the idea of this issue and not about the wording.

[adamsilver]

@kizu, what did I say to cause you to think I was being passive aggressive? I don't see which part of my feedback wasn't constructive. Surely it's you that's derailed the conversation by moving the subject away from the cursor and toward me/my apparent tone/etc.

[kizu]

@adamsilver Your first comment here looks much like a “straw man argument”. Your second comment confirms that you're not interested in a conversation about the topic, so this is the last time I'd ask you: if you want to be constructive, you can contribute to the conversation by either reformulating the wording that you find incorrect and/or by presenting your arguments without the snark. Otherwise, I would just need to stop to interact with you here.

[adamsilver]

I'll bring this back to my original question/comment.

What exactly do you mean by “interactive element”? Does that include, for example, labels, text, images, whitespace, form controls? Or are you just saying “buttons” should have the pointer?

In either case, can you please clarify exactly what you mean?

When it comes to buttons there's some ambiguity there too: <input type="submit">, <input type="button">, <button type="submit">, <button type="button"> and <input type="image">, or anything given role="button".

[pepelsbey]

All kinds of inputs are interactive elements too. For example textarea: it usually sussgest with beam cursor that I could type in it. Pointer would just mislead here. Another example: range element, which you mostly use for dragging a hangle to get a needed value. Sure, you could also click to get a specific value, but how you’d make it work: one cursor for clicking, one for dragging? I don’t think so.

As far as I see you need to specify not just “interactive elements” group for applying pointer by default, but somehow narrower group which would actually benefit from it. Links, buttons, sure. But what else?

[kizu]

Ok, I'll quote from the description of this issue:

this value is used by designers and developers not only for the “links” but for any other interactive element that did not have any other cursor defined for them, for example, for buttons.

I've highlighted there “that did not have any other cursor defined for them”. Text inputs, for example, already have a cursor: caret-like text one (there is ambiguity where both the non-interactive text can have a text cursor and textual inputs, but that's a separate issue altogether).

So, what I mean by “interactive elements” that should have pointer cursor (or, essentially, a cursor that is different from the default one) — any element clicking on which once with the primary click would result in an action. If clicking on it won't result in an action, then it shouldn't have a pointer cursor. If there is a more common or encouraged action that could happen when you interact with an element (like dragging for elements that also can be clicked), then, of course, the more fitting cursor should be applied.

And, yes, any button-y things like inputs with types button or submit or image, if clicking on them is actually doing something, then yes, they should have a pointer cursor. As well as labels for checkboxes and radio buttons (for those which would change the state, so the label for selected radio button shouldn't have a pointer cursor etc.)

Static text, whitespaces (uh), images — unless they're interactive, should have the default cursor (or more appropriate like the text one for text).

Labels for text elements or for other inputs that could get focus… I'd say pointer would be ok as well, but only if there'd be also a visual highlighting of the element which would become focused on hover.

And I think that cursor over labels is really important, as it would mean people would know that they could actually click on those labels to interact with the associated inputs. Otherwise, people who have used to badly designed forms that don't have interactive labels wouldn't dare to click on the labels and would spend more time struggling to hit the smaller radios or checkboxes.

Nobody is arguing that each HTML element should be used properly. That they should have all the available states designed nicely and distinctively. But the cursor should be one of those tools that developers and designers should be able to point to the interactive elements (sorry for the pun). Yes, this cursor won't help for those who're using alternative input methods. But if we can help those who're using mouses and trackpads — why not? And if we would have ways to find how to help in those alternative cases only — why wouldn't we use them? We should strive to make things better wherever we can, not discard those partial solutions that are obviously won't work in the conditions they were not supposed to.

[AmeliaBR]

Yes, most elements are or could be interactive, so a more precise definition would be useful.

The key feature of buttons and links is that a single click, with the primary mouse button, triggers an activation behavior. The finger pointer cursor has therefore come to mean "click here".

Working from @kizu's proposed text:

'pointer'
The cursor is a pointer that indicates an interactive element, clicking or tapping on which would result in any action (for example links and buttons).

We can replace "any action" with a more specific description:

'pointer'
The cursor is a pointer that indicates an interactive element with a primary activation behavior triggered by a click or tap (for example, links and buttons).

And while we're editing, we could add a visual description, to be consistent with other descriptions in the list:

… Often rendered as the backside of a hand with the index finger extended.