found drama

get oblique

“Is it a button?”

by Rob Friesel

It started simply enough.  A simple1 question:  “Is it a button?”  Referring to this:

Flickr's "All Sizes" button

This is (of course) the “All Sizes” button for any given photo on Flickr.  And (also “of course”) depending on how pedantic you want to get and/or how technical, it’s arguably not a button at all:

Flickr <a> as button

…it’s an <a> masquerading as a <button>?  Or is its “buttonness” defined by its appearance?  Or is it defined by its function?  Or by some other, harder to define, harder to quantify quality?

It’s an interesting question.  On the web—where anything can “be a button”—what makes something a button?  What instills an object with “buttonness”?  Let’s try a few definitions on for size:

  1. Only a <button> is a button. If we wanted to be strict about it, this gives us a good baseline.  Only that won’t work in any practical sense because then hardly any modern site actually has a button.
  2. Any <input> element in the DOM with a type of button, reset, or submit. (And maybe also type of image?)  Again, this is a decent “strict” definition to use as a baseline but probably not one that is terribly practical.  But certainly this gets us closer.  Some flexibility in the input types.  But still, when I looked at’s homepage, I saw only two <input> elements in the mark-up—and neither was a button.  But this arguably isn’t a terribly good definition for a button anyway because you’re still just one line of CSS away from having an invisible button.  (And what good is an invisible button?)
  3. If it looks like a button (and quacks like a button?) then it must be a button. Sufficiently vague?  This starts to feel more correct though.  Someone needs to be able to look at something and say “when I click on this, something will happen”.

But that brings us around to our original question:  is it more the look of the thing that makes it a button? or is it the action of the thing that makes it a button?  We know that it can’t be a strictly technical, strictly mark-up definition—because then hardly anyone would have buttons.  Where then is the middle ground?  What bastardized hybridization of links and graphics and input mark-up and JavaScript2 turn a “simple link” into button?

Because a link isn’t a button, right?  Unless it is a button?

Let’s agree to disagree here; let’s at least settle on this much:  there are going to be some times when a link and a button are visually indistinguishable from each other; and there will be times when a link and a button will be behaviorally indistinguishable from each other.  So perhaps we can start with this premise to at least differentiate these two concept (maybe un-muddy the waters a little bit):

A link is a navigational tool that moves the user between separate pages (and not necessarily within a given site) with no expectation other than acting on that navigation; a button acts on an object within the page and the user expects some non-abstract contextual change as a consequence of acting through that button3.

That being said, from a functional perspective, “buttonness” comes from performing an action.  (Any action?)  What about format then?  What is the shape that a button takes?

A couple of questions come to mind almost immediately:

  • Must a button have a border?  If not, do you embellish in some other way?
  • Will your buttons have icons?  Always?
  • Will your buttons have text?  Always?
  • Do your buttons ever contain (or is it “conceal”?) a menu of additional/alternate/secondary actions?
  • Are buttons always bound to toolbars?  Or can they show up anywhere?

In other words:  not so obvious, not so straightforward.

A few cases to consider:

It was their button example that started this whole thing; vide supra.  Their design seems to eschew “buttons” in favor of action-bound “links” (e.g., “Add a Person”, or “Add a Tag”).  Where they have buttons (which are not actually <button> elements but <a> elements), the buttons are borderless and ghosted until you hover over them; and they’re lined up as though they are in a toolbar but—if you have a portrait-oriented image—that invisible toolbar may extend beyond the boundary of the image (i.e., the object that those buttons act upon).  And then there’s the buttons bound to the comment form—which are blue and have no border but are <input> elements.  But OK—I’ve heard that the Flickr team are heretics.

Again, a design that seems to eschew buttons in favor of links.  But where we do have buttons, they appear to be graphics that are both bordered and embellished in such a way that they “come off” the page (i.e., with that raised plasticky 3D look) and they’re bound to specific widgets like the carousel (bordered, with icon, no text) or else they are bound to major actions like adding an item to the shopping cart (bordered, with icon, with text).


Hmm…  I see a lot of “links” and a few “icons” but no…  Oh wait, there’s a button.  (And for those keeping score: bordered, no icon, with text.)


A canonical example?  Bordered (and with simple corners!), no icons, just the text—and no real special embellishments of any kind save for a little light gradient.  (They’re even <input type="submit"> elements.)

Hmm… And hmm again.  A pattern emerges?  But does the border really make it a button?

Perhaps the whole thought experiment is a bit pedantic but in considering usability and user experience, the button ought to be (instantly?) recognizable.  Ultimately it comes down to having a consistent and predictable scheme across your application/site—so if you really aren’t interested in putting borders around every button then I suppose you don’t need to; perhaps always pairing icons with text is enough.  But if you’re to crib from the big successful players then we can infer that there is some magic fairy dust sprinkled onto the border.

For my money, I’m not a fan of the “ever-present” border—buttons are usually in toolbars (right? no?) and that ought to be enough to give away its intended purpose.  But I think I can come around on the borders.  What about you?

  1. Really? Simple? []
  2. If there is any need for JavaScript at all. []
  3. Does that clear things up?  No, not for me either. []

About Rob Friesel

Software engineer by day, science fiction writer by night. Author of The PhantomJS Cookbook and a short story in Please Do Not Remove. View all posts by Rob Friesel →

5 Responses to “Is it a button?”

fogus says:

I have two simple rules:
1) A button is a <button> and should be used to do some sort of process. Whether that means it redirects or not is irrelevant.
2) A link is an <a> and should be used for navigation.

You can dress up the latter to look like the former. However, there’s no real need to do that because once you live by those 2 rules your whole outlook on how you design pages and webservices changes.


EDIT: re-added the commenter’s button in #1.

Joel says:

It’s interesting that your previous post link looks like a button and the “submit comment” button looks like a link.

Or is it that your previous post button acts like a link and your “submit comment” link acts like a button?

Question: should a link always have a target URL?

found_drama says:

@Joel– Can you tell that this design pre-dates the post? (BTW- it is the former.) As I am currently satisfied with how these look, I’m leaving them as is. But you know what they say: perfection is version 1.0.1? 😉

As for your question…

This is a tough one. My gut says: “Yes. I would say that a link should always have a target URL.”

But we can also clearly see plenty of examples where “a link” does not exactly or does not quite have a target URL. Referring back to two of our examples above… Flickr uses links with target URLs that are then hijacked by JavaScript to do some DOM trickery. Meanwhile, Facebook’s home page is peppered with what look like links but are actually button elements in the mark-up (wrapping span elements…).

The waters seem muddier and muddier all the time.

So… an <a> or an <button> may be used to wrap text that looks like a link but acts like a button. And a link may be attached to an image and look/act like a button but “merely” transport you to another page—and that makes it a link.

Still mulling. Still trying to come up with some canonical definitions.

Leave a Reply

Your email address will not be published. Required fields are marked *