Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
kizu opened this issue Nov 4, 2017 · 57 comments

Comments

@kizu
Copy link

commented Nov 4, 2017

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 frivoal added the css-ui-4 label Nov 4, 2017

@frivoal frivoal self-assigned this Nov 4, 2017

@frivoal

This comment has been minimized.

Copy link
Collaborator

commented Nov 4, 2017

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

@frivoal frivoal added the Agenda+ label Nov 4, 2017

@CyberAP

This comment has been minimized.

Copy link

commented Nov 4, 2017

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

This comment has been minimized.

Copy link
Author

commented Nov 4, 2017

@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 comment has been minimized.

Copy link
Contributor

commented Nov 5, 2017

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

This comment has been minimized.

Copy link

commented Nov 5, 2017

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

This comment has been minimized.

Copy link
Author

commented Nov 5, 2017

@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

This comment has been minimized.

Copy link

commented Nov 5, 2017

@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

This comment has been minimized.

Copy link
Author

commented Nov 5, 2017

@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

This comment has been minimized.

Copy link

commented Nov 5, 2017

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

This comment has been minimized.

Copy link

commented Nov 5, 2017

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

This comment has been minimized.

Copy link
Author

commented Nov 5, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2017

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

This comment has been minimized.

Copy link
Collaborator

commented Nov 11, 2017

@GreLI

This comment has been minimized.

Copy link

commented Nov 13, 2017

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

This comment has been minimized.

Copy link

commented Nov 13, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

@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

This comment has been minimized.

Copy link
Author

commented Nov 23, 2017

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 astearns removed the Agenda+ label Dec 5, 2017

@astearns

This comment has been minimized.

Copy link
Member

commented Dec 5, 2017

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

@FremyCompany

This comment has been minimized.

@kizu

This comment has been minimized.

Copy link
Author

commented Apr 18, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Apr 19, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2018

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.

@frivoal frivoal removed the Agenda+ F2F label May 9, 2018

@SelenIT

This comment has been minimized.

Copy link
Collaborator

commented May 9, 2018

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:(

@SelenIT SelenIT reopened this May 9, 2018

@FremyCompany

This comment has been minimized.

Copy link
Contributor

commented May 9, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 10, 2018

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

This comment has been minimized.

Copy link
Author

commented May 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 11, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 12, 2018

  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

This comment has been minimized.

Copy link
Member

commented May 16, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 13, 2018

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?

@ihodev

This comment has been minimized.

Copy link

commented Jun 13, 2018

I don't know. I like the 🎯

@bkimmel

This comment has been minimized.

Copy link

commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 7, 2018

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

This comment has been minimized.

Copy link

commented Sep 7, 2018

@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

This comment has been minimized.

Copy link
Collaborator

commented Sep 7, 2018

@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

This comment has been minimized.

Copy link

commented Sep 7, 2018

  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

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Sep 8, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 8, 2018

@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

This comment has been minimized.

Copy link
Member

commented Sep 8, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.