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

[frivoal]

I support Amelia's proposal.

[GreLI]

None of operating systems uses that cursor on buttons etc. So why in the web it should be different? Designers use this cursor because of ignorance and, presumably, to compensate bad design decisions when it's not obvious which element is actually interactive. Unfortunately, that doesn't make it accessible, because you still need to hover cursor over the element. Many devices even unable to do it at all. So, I'm against it. Please, don't make bad design decisions spreading.

[adamsilver]

I agree with @GreLI. Users don't know where the browser or OS ends, and the web page begins.

“There’s no distinction between what’s a browser, what’s a website, what’s an operating system” — Jakob Nielsen, Mobile Usability Futures

[FremyCompany]

If we do not update the default styles of native buttons, checkboxes, etc... then I disagree with this proposal. If the only use of pointer in the UA stylesheets is for links, then it should be stated in the spec as being for links-like things.

Changing the style of native buttons is going to be problematic for us as we have to match the Operating System guidelines. If you believe the operating systems should change their guidelines, I'd recommend you send that feedback to them, not to us.

[tantek]

I am concerned with changing this description which has been this way for a very long time (10+ years).

To consider this text description change, I would need to see additional tests (feel free to link to them directly here in comments) that demonstrate existing interop with the proposed change. (if there is not interop on it, or worse, interop against it, then I don't think we can make this change).

[AmeliaBR]

@tantek The original proposal would only change the semantics of when authors may select a particular cursor value for their content. There is nothing to test as far as browser behavior goes.

If the working group decides to go a step further, and also recommend changes to default user agent styles (as @FremyCompany suggests), then tests would be appropriate. The tests should be organized with other tests of the user agent stylesheets for HTML. In other words, they would be probably HTML tests (not CSS) and SHOULD tests (not MUST).

(As an aside, as I go to press the "comment" button on this very page, I notice that my cursor changes to a pointer. Now, I'm not saying that GitHub is a beacon of best practices in web design, but users are used to this behavior because it is used on all sorts of sites.)

[kizu]

When I wrote this issue, I proposed to only change the description, without enforcing it on browser vendors to change the default cursor for the buttons.

So I'd propose just the change of the wording to something like @AmeliaBR wrote at this comment for now.

[astearns]

(removed stale Agenda+ label - please re-add when needed)

[FremyCompany]

https://adamsilver.io/articles/buttons-shouldnt-have-a-hand-cursor-part-2/

[kizu]

I don't agree with that article as well, and it doesn't argue against any of the arguments in my article. Though I'm not sure all sides could come to any consensus, but from the usage in the web its obvious that a lot of sites use cursor: pointer for buttons and other interactive elements, and I'd say that the spec should follow the usage and mention not only links.

[SelenIT]

I agree that the issue is mostly about matching the reality where too many people (both devs and users) treat the pointer cursor as an (additional) indicator of "clickability", and where sometimes there is no clear distinction between different kinds of controls that one can activate. So I like the @AmeliaBR's suggested wording from the comment above.

However, I believe that the spec should warn against making the cursor change the only visual indicator of interactivity. Maybe it would be worth to add a note that using cursor:pointer for an interactive element must always be accompanied with distinct styles for its :hover/:focus states?

[AmeliaBR]

I believe that the spec should warn against making the cursor change the only visual indicator of interactivity.

Excellent suggestion.

Maybe it would be worth to add a note that using cursor:pointer for an interactive element must always be accompanied with distinct styles for its :hover/:focus states?

Distinct hover styles don't help on touch screens. Keyboard focus styles are already required & expected. Making buttons look like buttons and links look like links is still the best approach for pointer users, so they know to point the cursor at that element in the first place.

[SelenIT]

I'm pretty sure this trend is much older than the flat design trend. Changing the cursor for "all clickable things" to pointer was promoted as the "easy way to improve usability" (sic) at least back in 2007 and 2009. It seems that back then it was already more natural for web devs (and probably many web users) to think of 'pointer' as of clickability indicator, not navigation indicator.

I suppose that the main reason for that trend was lack of other interactive elements in early HTML and browser limitations for styling (e.g. supporting of :hover state for links only in IE5-6). This forced web devs to implement all interactivity through links and href="javascript:void()" pseudo-links, which inherited the link cursor. Other web devs who learned after such examples tended to treat it as the inherent part of the interactivity. Flash also had pointer cursor by default for its "push buttons" (clickable areas), which might further reinforce the "pointer means clickability" trend. But even if that trend emerged from misusing the tools and repeating design mistakes, now it is the reality that is hard to ignore...

[SelenIT]

JFI, MDN has been teaching web devs that cursor:pointer means "The element can be interacted with by clicking on it" since June 2017. If it is a mistake, isn't it a bit late to try to correct it?

[frivoal]

1. As long as we're talking about best practices, it does not seem inherently problematic to me that different people would have different opinions.
2. "Since June 2017" means about 1 year out of 20 since this has been first specified. So no, if this is a mistake to be corrected, it's not too late.

[css-meeting-bot]

The Working Group just discussed Change the pointer cursor to indicate any interactive element..

The full IRC log of that discussion

<dael> Topic: Change the pointer cursor to indicate any interactive element.
<dael> github: https://github.com//issues/1936

[SelenIT]

Interestingly, Gmail recently changed its cursor behavior: while in the "Classic" version of Gmail interface there was a clear distinction between "links to the objects" (individual mail items, folders etc.) with pointer cursor and "buttons of the actions" (reload, reply, delete, change settings...) with default cursor, in the "New" interface all clickable elements have the pointer cursor. Isn't this an evidence of the prevalence of the "pointer means clickable" approach on the web?

[ghost]

I don't know. I like the 🎯

[bkimmel]

I'm not a part of any formal W3C process, just a "concerned citizen of the open web" for whom finding this issue was the end of a long strange rabbithole that started with a chat thread questioning whether or not it was appropriate to use the "pointer" to indicate a "clickable" element (so i.e. the exact same thing you have all been talking about here for a while). I'll just share some observations I made along the way to provide an outside point-of-view:

1. The preponderance of practice on the web at-large is to use the pointer to indicate that the element under cursor is "clickable". I could provide a litany of examples, but perhaps the most salient is https://www.w3.org/ itself. See the "Go" (input type=button) for the search feature in the top right. If even the site of record for web standards deviates from its own established norm, it may be an indication that the members of the committee responsible for authoring the standard should consider how it reflects on practice. Even if it introduces some changes to the standard with respect to its stability, I'd urge the committee to consider that a state of practice where no one follows the standard is potentially a greater destabilizing influence on the strength of the standard than a language change that would align the standard with established practice.

2. Having crawled my way down the list of comments on this issue, I am hearing @frivoal 's point about the language in the standard as (to paraphrase): "The language in the standard is intended for browsers and authors will know they are free to do whatever they want." Just to color that in with my own experience on this issue: that's not what occurs. Roughly, here is what happens in practice: 1. Someone writes an authoritative article about how "You should only ever use pointer cursors for links". 2. They link to the language in the standard which supports that view. 3. Anyone questioning the obvious disparity between the claim made in the article and common practice, or considering the usability gains from trying to help users discern clickable things from non-clickable things is silenced. There is a step 4 for the .001% of people like myself that harbor a strange fetish for web standards that leads to this very issue, but most practitioners that care about web standards at all (which already feels like something much less than a plurality) won't get this far and so won't get the benefit of the nuance that @frivoal suggests.

3. Since I'm here, I'm not sure exactly what the protocol for suggesting changes to the committee is but I think I saw someone suggest splitting the semantics under "pointer" might allow the having of cake (keeping the current pointer definition stable as an indicator of a "link") concurrent with its eating (providing an additional cursor to indicate a broader class of "clickable" things as a non-breaking change). Seems like a good idea.

[frivoal]

Thanks for the feedback.

I'm not sure exactly what the protocol for suggesting changes to the committee is

You're following it perfectly: civil discussion in this github repo is the way it's done.

Someone writes an authoritative article [...] They link to the [...] standard [...] Anyone questioning the [...] disparity [...] is silenced.

Do you think it would help if there was some wording in the standard, not just for the pointer value but for the whole property, that says even though many values are described in terms of what they mean and not just what they look like, this is meant to be descriptive, and does not restrict authors from using them in other contexts if they feel it would be appropriate?

Or maybe just a note next to the pointer value that "This value is commonly, although not universally, used by authors to indicate all clickable targets, rather than just links".

[bkimmel]

@frivoal I would think for the case of providing an affirmative defense for practitioners who wanted to use the pointer (to e.g. create some distinction for clickable elements), the latter approach (a note positioned close to the pointer value) would be very helpful.

[frivoal]

@FremyCompany You were one of the main persons pushing back against the normative change. What do you think about the note (read the last 3 comments)?

[ooglek]

1. The goal is a clear and well-defined standard.
2. The goal of a standard is to create consistency across implementations.
3. The consumer of the standard is a human.
4. Humans benefit from and can thrive in a predictable, standards-driven environment.
5. Language is complicated, and subtleties in language can lead to ambiguity.
6. Ambiguity in standards should be avoided, as it can reduce consistency, regardless of how long the ambiguity has existed without challenge.
7. In common use, pointer evolved to communicate an ability to interact with or take action on an element to the viewer. That interaction has evolved far past links.
8. The definition of pointer should evolve to address the ability of the viewer to interact with an element, OR a new term should be created to communicate ability of an element to be interacted with and the viewer's ability to interact with said element, leaving pointer defined as is.

[FremyCompany]

I have not changed my point of view that if we do not require user agents to use the pointer cursor on buttons/etc then the spec should not be updated saying that the pointer cursor should be used to mean something is clickable, because that would mean that browsers are in violation of that spec.

[FremyCompany]

But I am not opposed to try to change the default cursor on buttons and other interactive elements, just don't think this is worth our time, and frankly Edge cannot commit on doing this, but if other vendors want to experiment with this, and can show this is a sustainable change, I'm sure we'd happily follow. But changing the spec in a way that makes every user agent stylesheet invalid without checking if this is fixable first doesn't seem the right way forward.

By the way, the <input type=button> on w3.org is actually a perfectly fine usage of the pointer cursor because if you click on it, you navigate to a new page, so it behaves like a link.

[frivoal]

As far as I can tell, we're still on the previous situation then. Browsers don't want to change what uses the pointer cursor by default, nor is spec text that suggests that it may be used for other things welcome as long as this is true.

@atanassov @astearns I don't think any new information has been added since we last discussed it, so it is not clear to me that it makes sense to try and rediscuss it on the call to try and overturn the previous resolution. At the same time, it is also clear that this resolution does not satisfy the person who reported this issue and a number of people who are in agreement. What do we do? Mark it as an objection and move on? Reopen anyway? something else?

[kizu]

@FremyCompany

not be updated saying that the pointer cursor should be used to mean something is clickable, because that would mean that browsers are in violation of that spec

I can only repeat myself there: #1936 (comment)

I'm not sure why you're talking about should, while right now this part is not normative, and the proposal is not about changing that, but basically change the note which is more directed at developers rather than browser vendors. And if we'd want to convert this into a normative wording, we could always use may, so everyone (browsers included) could choose which one to use. Right now the situation is such that this part is interpreted by a lot of developers in a way they oppose using pointer cursor which often leads to a11y problems.

[tabatkins]

I agree with @kizu - it's easy enough to just say "this value SHOULD be used on links, and CAN be used on other interactive elements to indicate 'clickability'". Or even upgrade the CAN to an actual 2119-MAY.

(I also use pointer in this manner, so helping textual literalists get over themselves would be a net benefit I think.)

[css-meeting-bot]

The CSS Working Group just discussed Pointer Cursor wrangling, and agreed to the following:

• RESOLVED: Add sentence "Authors should use pointer on links and may use on other interactive elements" To UI4

The full IRC log of that discussion

<dael> Topic: Pointer Cursor wrangling
<dael> github: https://github.com//issues/1936#issuecomment-419616109
<dael> florian: I think we have strong consensus that we do NOT want to change UA requirements as to what they should do with pointer cursor. But there is a fairly large contingent of authors that think this is an author requirement and if you do pointer on anything other then link it's invalid.
<dael> florian: Large part of web does things like pointer on button
<dael> florian: Is there room for a note or some wording to say UA do links and links only, but authors can put it in other places
<dael> astearns: Last comment in issue TabAtkins suggested the sentence [reads]
<astearns> this value SHOULD be used on links, and CAN be used on other interactive elements to indicate 'clickability'
<dael> astearns: Is that sufficient? Acceptable?
<dael> florian: replace can with may but yes
<dael> fremy: not thrilled but don't want this thread open for 250000 years and this coming back up all the time. Still wrong because people have been misusing something and people pointed out we're misusing it and now we have to change requirements because we pointed that out
<dael> fremy: It doesn't make sense. Either we say it should be used and change UA style sheet. Why say can if we don't do it? I have mixed feelings. I won't object to a may. It's wrong, but I won't object
<dael> TabAtkins: That browsers can't change their behavior doesn't have baring on how a lot fo heavy usage leads to the value's usage. Legacy constraint on browsers shouldn't constrain us here. THis is about matching author expections. People expect this to work in a particular way.
<dael> astearns: Objections to adding the proposed sentece: this value SHOULD be used on links, and MAY be used on other interactive elements to indicate 'clickability' to UI 4
<dael> astearns: the pointer value SHOULD be used on links, and MAY be used on other interactive elements to indicate 'clickability'
<tantek> +0 sounds ok, still reading
<dael> florian: Should this be "authors should use" unstead of "should be used"
<dael> TabAtkins: It's on UAs.
<dael> florian: Do we want to say UA may apply to others?
<dael> TabAtkins: That's why I started with a can
<dael> florian: Is sentence meant for author and ua or just author?
<dael> TabAtkins: Both author and UA. I don't think it's bad if a browser changes to pointer on clickable things
<dael> AmeliaBR: We already agreed to UA must apply pointer on hyperlinks
<dael> AmeliaBR: more passive voice this cursor should be used could be included without cancelling the must
<dael> florian: I don't object to current. If it's meant as vague I'm okay with vague
<tantek> ok with CAN or MAY
<tantek> though slight preference for MAY
<dael> dbaron: Good to be clear who requirement is on
<dael> astearns: Not vauge, it applies everywhere
<tantek> also going to note for the record that no one followed up with tests as I requested last year in the issue :P (unless I missed something? searched whole issue for "test")
<dael> AmeliaBR: Have an explicit requirement on UAs. Another sentence could be authors should us it on any other element that behaves as a link and may use it to indicate clickability
<dael> florian: There's no UAs must not
<tantek> https://github.com//issues/1936#issuecomment-346420266
<dael> AmeliaBR: Exactly. No negative about UAs applying to other elements
<dael> florian: Like that better
<dael> astearns: Does reduce confusion
<dael> astearns: Object to scoping this sentence to jsut authors?
<dael> astearns: Proposal:": Authors should use pointer on links and may use on other interactive elements
<tantek> no objection
<dael> astearns: Obj?
<dael> RESOLVED: Add sentence "Authors should use pointer on links and may use on other interactive elements" To UI4

[frivoal]

Marked as not needing tests as this is a change to author requirements, not UA requirements, and we don't test those.