Hacker News Reader

Comment by bretthopper | Hacker News Reader

One interesting difference: Google just uses <div> for their buttons instead of <a> tags or even <button>. They also don't set cursor: pointer (the hand) for them.

Any UI people want to comment on the best practice for cursor styles? I always figured pointer should be used for all buttons or links that have an action attached.

View on HN

I, personally, hate buttons without cursor:pointer. Hover effects are nice and all, but they're often rather subtle, and your eyes are attuned to the cursor already. Changing it is extremely visible, and gives you immediate feedback that you're hovering something actionable. Anecdotal, but I find I "see" when my cursor enters a clickable region much more quickly if the cursor changes - I click sooner, rather than making sure it's positioned inside the element.

I find that I subconsciously interpret cursor:pointer as "clicking here will do something with GET semantics" vs. cursor:default as "clicking will do something with POST semantics". I feel about the same way about cursor:pointer-styled buttons as I do about plain blue-underlined "Delete" links.

I wonder if that's born from OS UI semantics... interesting. I wonder what pushed us in opposite directions.

Well, the old technical limitations of the web have muddied the affordances somewhat, but my rules is generally "add cursor:pointer if the button behaves like a link, leave it unchanged if the button behaves like a button".

Most of the G+ buttons actually behave like buttons, i.e. you click on them and something happens on the current page. They don't have cursor:pointer, but they have other standard button hover effects. Pre-AJAX, the web had a history of tarting links up to look like buttons so they would seem more "clickable". Those kinds of "buttons" should get cursor:pointer, but not any other hover effects.

My rule is add cursor: pointer if you can click on it.

Just because browsers didn't do that in the past for form buttons doesn't mean they did the right thing.

Agreed completely. At minimum, and this should be obvious, but you should never leave the text/I-beam cursor on something that can be interacted with (e.g. buttons, sliders, tabs). (I would have only upvoted you, but with hidden scores, who does that help?)

(It's meant you've expanded on ars's point, which is a win from my point of view.)

This is absolutely terrible for accessibility. Screen readers will not handle these buttons properly leading to a significantly more difficult experience. James Edwards actually talked about this at The Highland Fling conference a few weeks back.

Good point on accessibility. Anyone have links to making your UI accessible (including buttons)?

Here's a pretty good introduction on ARIA which is what Google uses to make their web sites accessible: http://msdn.microsoft.com/en-us/scriptjunkie/ff743762

The Google buttons do use the ARIA role="button" attribute, which should let them work in screen readers.

Or for people using Vimperator/Pentadactyl :|

FWIW, I asked also this here: http://www.quora.com/Whats-best-practice-for-buttons-on-sing...

Would be cool to get more opinions on it.

Also note that the buttons in the header area of Google+ are <a> tags, probably since they actually link to separate pages. I guess that's Google's practice.

Yes, use pointer. I don't know why G doesn't, but that is not good practice. There should be a visual indication that an object can be clicked, other than a highlighted border.

Yes, changing the cursor to indicate the element can be clicked is the easiest method to communicate this and for the user to understand it.

But it is not unheard of since desktop applications most likely do not change the cursor hovering on a button. It is mostly a web browser feature.

It's always been my belief that one should try to stick to the browser's native behavior when possible. Web browsers (on personal computers) have pretty consistent pointer states for links (which take you to another page) and form elements (which activate an ability on the current page [with the exception of 'submit' buttons]).

In this regard it seems like Google is doing the right thing. Only run against the user's previously acquired assumptions if there is a very good reason.

Is there some downside that I am not seeing with relation to using <button> instead of a <div>?

I have always used <button> tags (occasionally <a> tags as well). Along with a css reset and some custom changes I can make the button look like anything I want.

Reply on news.ycombinator.com