Csswg-drafts: [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.

[FremyCompany]

I don't think this issue is ready to be approved, as there is not broad consensus that the current mis-use of this cursor is something that makes sense from the user point of view.

There is been feedback on twitter from me and other people that a "hand" cursor in a browser means I should be able to ctrl+click or click using the mouse wheel to open the link in a new tab. I sincerely believe that buttons that do not adhere to this shouldn't have a hand cursor, and that doing so is an authoring mistake. Authoring mistakes shouldn't be encouraged in specs.

For instance, HTML Tables shouldn't be used for layout, yet a lot of developers used them for layout; still, the spec never stopped saying you should not use them for layout.

[kizu]

I should be able to ctrl+click or click using the mouse wheel to open the link in a new tab. I sincerely believe that buttons that do not adhere to this shouldn't have a hand cursor, and that doing so is an authoring mistake.

I disagree. Hand cursor is not the only thing that shows that something can be open in a new tab, as there is, for example, much better sign: tooltip with an URL. Also, I remember a lot of browsers allowing to submit forms in a new tab for button, so ctrl+click is not reserved only for links. And this behavior potentially can be changed by developers as well.

Having a pointer cursor (or any change) over a button makes it more accessible. It is a cheapest way to make a button accessible for users with hand motor skills problems and/or vision problems (when it can be hard to see the existing low-contrast change in button's state), as it makes it much easier to understand when the cursor is over a button.

But I have written all of this in my article, so I, again, repeat myself, oh well.

[kizu]

That said, again: this is a kinda subjective issue. There are a lot of people who won't even stop putting pointer cursor on buttons. This is a place where the spec should follow the usage, as current outdated text doesn't make any sense in the current state of the web.

Also: you’re never looking at just an element’s cursor: you’re looking at element’s content and context as well. And if you expect for this exact element to have and url behind it — the problem would be that it should be a link in the first place, and the cursor won’t have anything to do with this. You won’t expect from a “delete item from the cart” button to be a link. And you shouldn’t even if it would have a cursor.

[frivoal]

One thing that makes this issue tricky is that since we let UAs pick their own design for the different types of cursors (which is totally the right thing to do), we cannot prescribe what the cursors should look like (although we can give suggestions), but instead we describe them by what they should evoke to the user.

The pointer cursor has been described as evoking "this is a link", as it is what it was initially displayed for, so there was that mental association. This is not exactly the same as saying "use this for links and for links only". Authors may do whatever they want with it. At the same time, good UX usually relies on familiarity, so using the cursor that makes people think "this is a link" on non links is somewhat questionable.

Now, what happens is that many (but not all) people have been routinely using it to indicate "this is clickable". So a good way to describe which cursor we want the UA to show can now be "the one that often gets shown to indicate things are clickable". But because of the same UX principles, that also comes out as an endorsement for using it for more than links, which may or may not be intended.

I am not sure whether we should prioritize being descriptive of what it is often used for, or being prescriptive of what it should be used for. If the former, Amelia's suggestion is pretty good. If the later, it may still be good if we agree that using it on all clickable things is good, or not if we think that it really ought to be used just on links.

Adding "Often rendered as the backside of a hand with the index finger extended." should be non controversial (and purely editorial), so I'll do that part.

For the rest, I don't have a strong opinion, so I'll go with the group's preference.

[SelenIT]

At the same time, good UX usually relies on familiarity, so using the cursor that makes people think "this is a link" on non links is somewhat questionable.

In my opinion, the key question is what the pointer cursor _really does make people think_ nowadays. I can't find any research data on this topic, but occasional web devs surveys that happen in social media discussions tend to imply that "hand pointer means clickable" concept is now significantly more popular than "hand pointer means some resource to navigate to". It may or may not to be a result of misusing/abusing the pointer cursor by the whole web dev community in the past, but this seems to be the reality. As @kizu points out, the more reliable _indicator_ of the link is now the dynamic status bar displaying its URL when hovering the link. And I suppose that the spec should neither _describe_ the way of thinking that is not in line with this reality nor _prescribe_ doing something that contradicts it. It's probably too late to try to "undo" the shift in the pointer cursor meaning that already happened, at least on the web.

So I believe that Amelia's suggestion is really the clearest way to _specify_ the current state of things. The only thing I would add to it is some warning or note that such interactive elements _must_ be identifiable without cursor as well.

[css-meeting-bot]

The Working Group just discussed Pointer cursor over interactive elements, and agreed to the following:

• RESOLVED: Add often-rendered-as sentence to pointer definition

The full IRC log of that discussion

<fantasai> Topic: Pointer cursor over interactive elements

<fantasai> florian: Almost editorial, but maybe not

<fantasai> florian: We describe cursors that can be chosen with the 'cursor' property

<fantasai> florian: Didn't require any particular iconography

<fantasai> florian: So we describe them in terms of what they are used for

<fantasai> florian: e.g. “This is the thing you see when you point at links”

<fantasai> florian: It's descriptive, but also normative.

<fantasai> florian: Peoplementioned that even though that used to be a reasonable statement

<fantasai> florian: But now lots of authors use that cursor not only on links, but all clickable things

<fantasai> florian: If you say “The thing you only see on links”, ppl get confused

<fantasai> florian: Don't you mean “The thing you see on clickable things”?

<fantasai> florian: So we could change the description

<dbaron> "The cursor that is generally used to indicate links or other clickable things." ?

<fantasai> florian: But then that looks like it suggests a change to the UA style sheet

<fantasai> florian: It doesn't seem like anyone is suggesting to change the default behavior

<fantasai> florian: We can either update the description, have it not match the UA style sheet

<fantasai> florian: Or make the description match the UA stylesheet, but not common practice

<fantasai> smfr: ... authoring conventions

<astearns> amelia's suggestion: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-341987070

<fantasai> smfr: On MacOS we definitely don't show the hand on clickable things in general

<fantasai> smfr: If we knew what OSes do, that' be helpful

<fantasai> florian: It seems like on native UIs, it's not the cursor used on clickable things

<fantasai> florian: but on Web pages it is

<fantasai> smfr: So I would suggest we don't make a change

<fantasai> smfr: I don't think we should impose on users a difference between the Web view and things outside it

<fantasai> smfr: I think it wanted to indicate something like navigating away...

<fantasai> ...

<fantasai> florian: Fair amount of agreement on the thread

<fantasai> florian: The question isn't whether we should encourage pointer on buttons

<fantasai> florian: But how to describe pointer

<fantasai> florian: are we prescriptive or descriptive?

<fantasai> florian: If we're prescriptive, then agreed with you

<fantasai> florian: I don't have a strong opinion, fwiw. Just reporting the disagreement

<fantasai> astearns: Not clear to me whether current spec is prescriptive or descriptive

<fantasai> florian: kinda both. Used to be consistent between the two, not so much now

<fantasai> florian: We could maybe have descriptive and prescriptive bits

<fantasai> ?: I would be OK with that

<fantasai> florian: “Typically rendered as”

<fantasai> astearns: If we were going to start over... but I don't think we need to change.

<tantek> indeed

<fantasai> astearns: If there's nothing testable that we're making the change for, no need for a change

<fantasai> smfr: Ask browser vendors ... UA stylesheet ... buttons

<tantek> so informative?

<fantasai> florian: Proposed resolution is don't change the sentence, add a clarifying rendered-as sentence

<fantasai> astearns: why?

<fantasai> florian: Most values have such a sentence, and since there seems to be some confusion, having a bit more visually descriptive sentence could be useful

<fantasai> I initially thought 'ponter' was just the arrow.

<fantasai> s/ponter/pointer/

<bradk> Cursor: finger

<fantasai> florian: pointer is closed hand pointing

<fantasai> astearns: hearing no objections

<fantasai> proposed resolution: Add sentence describing what 'pointer' looks like.

<fantasai> tantek: are we adding screenshots?

<fantasai> astearns: Doesn't seem necessary

<fantasai> florian: Also the spec itself is interactive, you get the value as you hover over it

<fantasai> RESOLVED: Add often-rendered-as sentence to pointer definition

<fantasai> Florian, maybe extend the 'cursor' onto the <dd>s as well?

<fantasai> github: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-341987070

[SelenIT]

Despite the resolution above, the question "whether we should encourage pointer on buttons" seems to be what really confuses people, not the appearance of the cursor. There is very little confusion about how cursor:pointer looks like (although the historical IE5's cursor:hand might be the more intuitive name:). People would like to know whether using cursor:pointer for things other than links is conforming or not. The current spec text, even with "typical rendering" clarification, doesn't provide a clear answer. If the more-or-less official position of the WG is that the purpose of that cursor is "to indicate something like navigating away", I believe it should be somehow reflected in the spec (although the whole concept of "navigating away" is also rather blurred in the modern world of SPA and other async things).

IMO, closing the issue was rather premature because the main underlying problem wasn't solved:(

[FremyCompany]

@SelenIT How is the spec not clear?

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

And the general definition of a link is:

a link from a document to another location or document, typically activated by clicking on a highlighted word or image on the screen

The issue is being resolved won't fix means that this text will be kept, and the question about whether this cursor should be used on buttons that do not trigger a navigation is answered as "no, you shouldn't".

There is agreement between the two vendors building operating systems shipping with cursors (Apple for MacOS and Microsoft for Windows) that the web should not redefine the semantics of these cursors.

ASIDE: Whether the navigation is internal (SPA) or external is not relevant. Links in an iframe have always only navigated in that iframe; single page apps can have their own concept of navigation and it doesn't have to be 1-to-1 mapped to the browser navigation stack but a pointer cursor should reflect some navigation to a new location.

[frivoal]

To add a little more nuance to @FremyCompany , while browsers have indeed said that their answer to the question of whether it is a good idea to use the pointer cursor on things other than links, this does not make pages that do that non conformant. It merely makes them bad ideas according to Apple and Microsoft (and people who agree with them).

Yes, there is a value judgement implied here, and the spec is recommending that cursors made for links are used (only) on links. But this is not a matter of author conformance.

There would be no need to have a cursor property at all if authors could not change the cursors to suit their tastes.

Effectively, you can read the whole cursor section of the spec as

When the author picks the xxx cursor, the UA must render the cursor in a way that suggests yyy, which typically look like zzz.
Note: Which cursor to use when is subjective, and authors are free to make that choice. However, authors should generally not use a cursor that suggests yyy if they don't mean yyy.

I would rather not rewrite the whole cursor section to make that more obvious than it currently is, as I don't think this would have much of an impact in practice, and I'd hate to accidentally change the meaning of text that has been stable for the better part of 20 years.

PS: I don't think author conformance is a particularly interesting topic in CSS in general. There are, in various specs, cases of "please don't do that", but the behavior needs to be fully defined anyway for interoperability, and those are best understood as advice on best practices, rather than rules to be blindly enforced. Most such things require human judgement anyway.

[FremyCompany]

Right, authors are obviously free to be their own judge in the end. There is nothing in the spec saying that authors must not use this pointer cursor on buttons.

[kizu]

There is nothing in the spec saying that authors must not use this pointer cursor on buttons.

But

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes.

There is no normative terminology in cursor's definition, though, but the part about the cursor pointer as also not an example or a note, so its a gray area. If it is something that is supposed to be read as MAY, then it should be clearly stated as it is. Otherwise, people would misinterpret and use the spec, threating this part as a rule, enforcing the absence of cursor pointer on buttons.

[SelenIT]

How is the spec not clear?

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

@FremyCompany, people seem to understand the word "indicates" differently: while some people read it as "the cursor _suggests_ that the object under it is a link", some others read it as "it's that hand-with-finger cursor that _usually appears_ when you hover a link". So it seems to be not clear if the "indicates" part is about the _meaning_ of the cursor or just about its _appearance_. I'm afraid that with the new "often-rendered-as" addition the second interpretation can become even more popular.

treating this part as a rule

@kizu, from the discussion above and the latest @FremyCompany's and @frivoal's replies I read that it still _is_ the rule (alas)... but not the law:). It's more like SHOULD (NOT) than MAY (i.e., it's OK to set this cursor to buttons if there are really good reasons to do so beyond personal aesthetic preferences, e.g. some A/B testing or usability study data).

[frivoal]

There is no normative terminology in cursor's definition, though, but the part about the cursor pointer as also not an example or a note, so its a gray area. If it is something that is supposed to be read as MAY, then it should be clearly stated as it is

This section is normative, and to be read as MUST. But the requirement is on browsers. Browsers MUST show that particular cursor when authors specify it. Authors may do whatever they want, that's what the property is for.

[frivoal]

I read that it still is the rule (alas)... but not the law:). It's more like SHOULD (NOT) than MAY

No, the rule and law is a MUST, but it's on browsers.

The phrasing is not changed, because browsers think that this value was introduced for a particular purpose, and they do not want to change the statement about what that purpose is. But what authors do with it is 100% up to them.

[SelenIT]

@frivoal, I meant the "rule" that

However, authors should generally not use a cursor that suggests yyy if they don't mean yyy.

Sure, authors may do whatever they can (and whatever browsers support), but still there are some "good practices" that the spec specifically endorses/recommends, aren't they? For many developers, giving the _proper_ cursor for all "interactive elements with a primary activation behavior triggered by a click or tap" definitely feels like a good practice... but, unfortunately, the current spec isn't much helpful to determine which cursor is _proper_ for them. There is a long-existing developers convention that it's pointer, the spec seems to disagree, but it's not clear how strong that disagreement is...

[frivoal]

still there are some "good practices" that the spec specifically endorses/recommends, aren't they?

@SelenIT Yes, as long as we're clear that we are indeed talking about endorsing best practices, not about conformance. One is subjective, the other is objective. We are in subjective territory here.

As for the best practice, UI conventions in all operating systems I can think of (and certainly among those represented in the CSS-WG), as well as in the default styling for the web is that the default cursor is used for buttons and other clickable things, and that only hyperlinks get the pointer cursor. My understanding was that Apple and Microsoft felt rather strongly about this, and wanted to maintain the consistency between the native UI and the web. No-one in the group seemed to disagree (or at least not strongly enough to push back).

I suspect the trend about using pointer over all clickable things started roughly with the flat design trend as it makes it more difficult to visually identify what is clickable or not.

[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/w3c/csswg-drafts/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: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-387972281

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/w3c/csswg-drafts/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/w3c/csswg-drafts/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.