Digital Web Magazine

The web professional's online magazine of choice.

Push my button

Got something to say?

Share your comments on this topic with other web professionals

In: Articles

By Aaron Gustafson

Published on September 25, 2006

If there’s one element I think doesn’t get enough respect, it’s gotta be button. It’s played second fiddle to input in tutorials and form examples for as long as I can remember. The few times it actually did get some attention, the lowly button was used and abused by the DHTML crowd—forced to accept obtrusive inline event handlers and other such nefarious crimes against semantic markup.

In fact, I think the atrocities committed against the button element have directly contributed to its scarcity in today’s web applications—its reputation tarnished, its meaning lost. Consequently, few modern web developers ever consider this protean form control for their projects. That’s a real shame; button is quite flexible and is a great asset to have in your HTML toolbox. Let’s begin our exploration of this undervalued element by examining its usage in comparison to the common input elements that have taken its place.

Functional Comparison

The most common input idiom is a simple submit button, which appears on virtually every form we write. The familiar input syntax is dead simple:

<input type="submit" value="Submit" />

But indeed, so is the button syntax:

<button type="submit">Submit</button>

The two are identical in terms of functionality, but the button offers a much higher degree of flexibility. The input submit button is limited to displaying a simple string of text, while button can contain content with far richer semantic meaning. For example, we may want to add importance to part of the submit button’s text:

<button type="submit">
  Continue to the <strong>Next Page</strong>
</button>

Or we might use an image for clarity:

<button type="submit">
  <img src="next_page.png" alt="Continue to the next page" />
</button>

Beyond form submission, the button element can also replace a form’s input-style reset button:

<input type="reset" value="Reset this form" />

can be simply re-written as:

<button type="reset">Reset this form</button>

A button can even become the basis for script-based events by going generic with type="button", and hooking into it with unobtrusive JavaScript executed onload:

<button type="button" id="something-doer">Do Something</button>

Note: Such a generic, script-triggering button should only be generated onto the page via JavaScript, because the button would be pretty useless without JavaScript enabled in the browser; there’s no point in giving people form controls they can’t use.

The real power of the button element, however, comes from how we can style it. Let’s take a look at the options available to us.

buttons with style

Unlike the input-based buttons, the majority of browsers do not force any particular design on the button element, leaving it a raw ingot which we can cast and shape to our liking. The image below depicts the submit-type button as rendered by default in the more popular browsers.

The BUTTON element default rendering in Safari, Firefox, Camino, Netscape and Opera on OS X and Internet Explorer, Firefox, Netscape and Opera on Windows XP.

You’ll notice that each browser (apart from Opera 9 on OS X ) treats button quite simply; a welcome change from the native UI-based input buttons in Safari and Camino seen here:

The INPUT-based submit button as rendered by Safari using the OS X UI form control.

Some may argue for the use of native form controls because they “feel comfortable to users,” but if you’ve ever tried explaining to a client why the buttons don’t match the design, I’m sure you can see where I’m coming from; after all, blue-glowing gel buttons don’t go with everything.

An example of the modern-looking INPUT-based gel button button sticking out awkwardly in a design.

Using the button element, we can create buttons that are far more stylish (and appropriate)

The same form example as above with a more appropriate BUTTON-based submit button

without resorting to those obnoxious <input type="image" /> buttons that feel the need to include the mouse-pointer’s coordinates in the submitted form data. There’s a time and a place for that type of input, but it isn’t in most common forms.

An example please…

I’m sure most of you have already realized the power button affords you, but, for those who still need a bit of convincing, here’s a quick example.

Last autumn, I was working on a virtual Christmas card for my former company. In the card, the “Grab Bag O’ Goodness,” the user was expected to choose a charity for us to contribute to in lieu of sending them a tacky corporate gift. So I created a simple form to do the job; below is the important bit:

<ol id="choices">
  <li id="choice1">
   <button type="submit" name="present" value="1">1</button>
  </li>
  <li id="choice2">
   <button type="submit" name="present" value="2">2</button>
  </li>
  <li id="choice3">
   <button type="submit" name="present" value="3">3</button>
  </li>
  <li id="choice4">
   <button type="submit" name="present" value="4">4</button>
  </li>
  <li id="choice5">
   <button type="submit" name="present" value="5">5</button>
  </li>
</ol>

If you’re wondering why the content of each button is so vague, it’s because we didn’t want to skew the results by saying the name of each charity. We opted for providing a gift number for each button, and, using CSS , turned it into a wrapped present.

The BUTTON element styled to look like a wrapped present.

Then, on :hover or :focus (giving IE a little nudge with the Suckerfish Shoal), we revealed an icon (complete with little animated stars sparkling around it) that hinted at what the recipient charity might be—in this case, the Greater Hartford YMCA :

The hover state given to the BUTTON element: a basketball surrounded by twinkling stars.

Using CSS-based image replacement, it was relatively simple to add the window dressing needed to make this form entirely un-form-like. It sure beat using a series of radio buttons or creating an unnecessary Flash piece. Plus, by using multiple named submit buttons, I could track the value chosen for present on the backend without needing to include any additional fields or require any additional action on the part of the user, thus greatly simplifying both the form’s HTML code and the UI.

Taking It Further

Using the button element instead of an input opens up a world of opportunity for exploration. Consider the following possibilities:

<form id="chooser" action="chooser.php" method="post">
  <fieldset>
   <legend>Please choose a plan from the following</legend>
   <ul>
    <li><button type="submit" name="plan" value="basic">
     <h3>Basic Plan</h3>
     <p>
      You get 20<abbr title="gigabytes">GB</abbr> of
      storage and a single domain name for
      <strong>$2.99/<abbr title="month">mo</abbr></strong>
     </p>
    </button></li>
    <li><button type="submit" name="plan" value="pro">
     <h3>Pro Plan</h3>
     <p>
      You get 100<abbr title="gigabytes">GB</abbr> of
      storage and a single domain name for
      <strong>$12.99/<abbr title="month">mo</abbr></strong>
     </p>
    </button></li>
    <li><button type="submit" name="plan" value="guru">
     <h3>Guru Plan</h3>
     <p>
      You get 500<abbr title="gigabytes">GB</abbr> of
      storage and unlimited domain names for
      <strong>$22.99/<abbr title="month">mo</abbr></strong>
     </p>
    </button></li>
   </ul>
  </fieldset>
</form>

becomes

A Web 2.0-esque design placed upon the above form controls.

Or

<form class="pagination" action="paginate.php" method="get">
   <ol>
    <li class="prev">
     <button type="submit" name="submit" value="1">
      1
      <span></span>
     </button>
    </li>
    <li class="curr">
     <button type="submit" name="submit" value="2">2</button>
    </li>
    <li class="next">
     <button type="submit" name="submit" value="3">
      3
      <span></span>
     </button>
    </li>
    <li>
     <button type="submit" name="submit" value="4">4</button>
    </li>
    <li>
     <button type="submit" name="submit" value="5">5</button>
    </li>
   </ol>
</form>

becomes

The above form controls laid out in a pagination scheme, complete with “Previous” and “Next” buttons.

From a markup standpoint, you can put pretty much anything inside your button elements. You are only restricted from using the anchor element (a) and other form controls (for obvious reasons). From a stylistic point of view, there’s very little you can’t do; so go out there and get creative with your buttons.

Got something to say?

Share your comments  with other professionals (30 comments)

Related Topics: XHTML, Interaction Design

 

Aaron Gustafson works as a part of Easy Designs, writes and speaks often on the various layers of the web standards cake, and works dilligently to improve the usability and accessibility of the web.

Media Temple

via Ad Packs