@jab Nice refinement!

I think it's an open question as to exactly where we want to use the default (arrow) cursor and the pointer (hand) cursor. I've never seen any definitive statement as to the original intent for each. I think the decision about which cursor to use is something of a design judgment.

One could make the case, for example, that a hand should only be used when a click would result in navigation. But that seems overly strict, and in any event, moving through a carousel does feel like a form of navigation.

Trying out this PR, I think using the hand cursor on these buttons feels like a win. I've put this on our develop branch, where it's now lined up for our next release (0.7.2). That'll probably happen in the next couple of weeks. At that point, this PR should close itself.

While I was at it, I've tried applying this to basic-page-dots. It feels good there as well, so that will show up in the next release as well.

I have UX expertise; here is the principle that calls for this change: When the mouse moves over a clickable element, but the cursor does not change to indicate that it's clickable, this sends the signal that it is not clickable, and indeed, many users therefore don't realize it is clickable, presenting a serious usability bug. I've seen a lot of carousel implementations, and this is the first I'd seen that didn't change the cursor to pointer for the clickable elements (whether dots or arrows).

The subtle thing isn't whether to use pointer while the mouse is directly over a "next slide" arrow, but rather how large to make the "hit area" around the arrow. I've seen implementations that make it only as large as the arrow icon itself, as well as implementations that make the entire right half of the image the clickable region for "next" (and likewise the left half for "previous"). The former is the safer choice, by the principle of least astonishment, as clicking a pixel just left of center resulting in "previous" can feel very surprising.

Hope this helps. Thanks for merging, and for applying the same treatment to the dots :)

While I'm comfortable with the use of the hand cursor in the carousel context, I think this is an interesting opportunity to explore the question generally for this project. For purposes of this discussion, let's assume all participants in this conversation have UX expertise.

I maintain there is no definitive statement covering the intent of the hand vs arrow cursor in web pages that provides sufficient guidance to make decisions like this. From what I can see, the CSS cursor property is supported as far back as IE 5.5, suggesting it was defined long before web developers might define their own components, and hence need any guidance as to when to use which cursor. Instead of guidelines, what the web appears to offer is a set of conventions that emerge from default browser styling for native elements.

As far as I can reconstruct: browsers typically style elements to show the hand cursor, text elements to use the i-beam, and (nearly?) everything else to show the default arrow cursor. That leaves a lot of clickable elements that use the default cursor:

• buttons
• check boxes
• radio buttons
• spin boxes (in input elements)
• dropdown arrows (in input elements like Chrome's input type="date")
• close boxes (date inputs, again)
• scroll bar thumbs

Since this project is trying to develop a library of general-purpose components along the lines of the native ones above, I think a defensible guideline would be to say that clickable elements should use the default cursor unless there's a strong case to be made otherwise.

I can see the argument for wanting to use the hand everywhere, but there are some downsides:

• A component that's close in nature to the native elements above should presumably adhere to the precedent they establish. We're working on a combo box component, for example, and I think it's reasonable to have that component's dropdown arrow button element show the default arrow cursor.
• Browsers appear to be very conservative as to when they use the hand cursor, and leave the decision to designers to opt into the hand cursor. The same rule of thumb might apply to the sorts of components we're creating here. I think it's plausible that, if HTML were to gain a native element, the default user agent styling would not include the use of a hand cursor. Instead, devs would have to specify use of that through the use of cursor: pointer. We might design these components as if they were going to be native.
• Using the hand everywhere erodes the value the hand's original (apparent) value of suggesting navigation.
• Other affordances such as hover effects can effectively communicate interactivity. Both the arrows in basic-arrow-selection and the dots in basic-page-dots have hover effects.
• User experience with common patterns inform their expectations. I think it's unlikely that a user who's seen a carousel would be confused as to how to use it, regardless of whether it uses hand or arrow cursors.

As I said above, I think the answer for a given component will require design judgment. My inclination is to reserve default use of the hand cursor for elements that feel like navigation, such as carousels and tabs. In other cases, the cursor should be left as the default.

Does any of the above change your thinking, or do you still feel that we should use the hand cursor for all clickable elements?

Apologies for the delay, and thanks for adding all that context, definitely relevant and helpful. You give some good counterexamples showing that whether an element is clickable or not isn't the surefire litmus test for using a pointer cursor that I made it sound like it was... based on browsers' default styling. This raises the question though of how much to consider browsers' default styles as guidelines for good design, versus other factors.

One indisputably more important factor than default behavior that you mention is adhering to good design principles, such as consistency, convention, and showing an element's function through its design. It's worth noting that some of these conventions (and even principles) may change over time in ways that browser defaults don't, since browser defaults often remain encumbered by historical forces or compatibility requirements, whereas common practices are free to modernize and respond more quickly to changes in the environment.

And another more important factor than defaults is the user's most common past experience. Defaults of course influence this, but they don't dictate it. For example, even though by default browsers give native button elements the arrow cursor on hover (as well as no other special hover styles, in direct violation of some good design principles), I bet the overwhelming majority of the time that a user has hovered over a button on the web today, the cursor has changed to a pointer—in spite of browsers' default styles— because some high percentage of sites override these defaults. I'm not sure if there's data somewhere on just how much of the time the most commonly clicked buttons (carousel nav elements, etc.) on the web have the arrow cursor on hover versus the pointer, but that would be extremely useful. In its absence, looking at what's done by the most commonly-used baseline libraries such as Bootstrap (which definitely uses cursor on button hover (and for carousel nav, etc.)) could be worthwhile.

I'm not sure if whether the click represents a navigation or not is the right litmus test, vs. some of these other factors, but probably worth considering too.

While no one can disagree with the idea of using good design principles, I do think it's an open question as to what constitutes good design principles.

As just one example, at the time of this writing, the Google home page uses hover effects on the primary search buttons, but leaves the cursor as the default. I have no insight into Google's process, but it would not surprise me if these two buttons have been studied in more usability tests than any other buttons on the web. My point is not that I want to follow Google's example, but rather that it's possible for informed, experienced designers with ample usability data to conclude that using the default cursor constitutes good design for this page.

I've started a wiki page on User Interface Guidelines to try to capture points like this. At this time, I only feel confident calling for the use of hover effects on all clickable elements, and the use of cursor: pointer on elements that perform navigation. We will likely revisit this question many times as we design and add new components to the project.

The original fix requested here was merged into master this morning as part of the 0.7.2 release, so I'd like to mark this particular PR as closed.