Quick HTML tip: Use the <button> element

Jan 26 2006

In Google’s recent Web Authoring Statistics study, in the section on the use of classnames, they commented:

The button class baffles us. We can’t really tell what what it is used for.

Perhaps they don’t have cause to build many web forms, but it was immediately obvious to me why a class of ‘button’ would be used so frequently. Consider a simple form (simplified for this example):

  1. <form action="login.php" method="post">
  2. Username:
  3. <input type="text" name="username" />
  4. Password:
  5. <input type="password" name="password" />
  6. <input type="submit" value="Log In" />
  7. </form>

We apply some CSS to make our input fields look nice:

  1. input {
  2. background: #000;
  3. color: #fff;
  4. border-bottom: 1px solid #666;
  5. border-right: 1px solid #666;
  6. border-top: 1px solid #ccc;
  7. border-left: 1px solid #ccc;
  8. }

Unfortunately specifying a blanket style for all inputs will also apply those rules to the submit <input> as well. The most obvious fix for this is to apply a quick class="button" to the <input type="submit" />, and reset the rules to make it look more button-like.

The third better way

Although it’s been around for a while, it seems that there are quite a few developers that are not aware of the existence of the <button> element. Easily styled and more flexible than an input, it removes the need to apply a class to inputs that are actually buttons:

  1. <form action="login.php" method="post">
  2. Username:
  3. <input type="text" name="username" />
  4. Password:
  5. <input type="password" name="password" />
  6. <button type="submit">Log In</button>
  7. </form>

Now our CSS will only style our text inputs, and we can happily style the button totally separately. You can also apply other inline styles to the text enclosed by the opening and closing tags:

  1. <button type="submit"><u>R</u>efresh</button>

Here a <u> tag is used to underline the first letter, perhaps to indicate the presence of a shortcut key.

So start using the <button> element and save yourself the hassle of trying to style submit inputs differently from text fields.

Filed under: XHTML.

Technorati tags:

Digg this article

Bookmark this article with del.icio.us

Previously: Ba-dum tish!

Next: IE7 Beta 2


Comments

Andy Saxton
924 days ago
Nice tip. The u tag is deprecated though I think. I won’t tell Patrick or you will never hear the last of it ;) I heard he had deprecated XHTML entirely though…
#1
Matthew Pennell
924 days ago
Only in XHTML 1.0 Strict – it’s still valid in Transitional (he said after checking through the DTDs…) ;)
#2
James Gregory
924 days ago
Although I haven’t seen it first hand, IE apparently has a quite flaky implementation of the tag. I think it posts the innerHTML of the button instead of the value, and also there’s no way to differentiate between which button was clicked.

Don’t hold me to that though; I should probably do some tests some time.
#3
Matthew Pennell
924 days ago
Not sure what you mean, James; the tag is functionally equivalent to an input of type=”submit”, it doesn’t have a value.

If you wanted to use the tag for other uses than submitting forms, you would be attaching onclick events to it, which AFAIK work exactly as you would expect.
#4
James Gregory
923 days ago
The problem is that if you have two button tags (of type submit) within a form, IE sends the value of both back to the server on form submit, instead of just the button that was clicked, like the input equivilant.

Also, I don’t know what the implications are for browsers prior to IE 6.

Ref: http://www.peterbe.com/plog/button-tag-in-IE
#5
Matthew Pennell
923 days ago
Why would you ever need to use two submit buttons, though? A submit button submits its form, it’s not supposed to do anything else.

If you’re doing something more complicated than that you are probably using Javascript – in which case you can use the JS to submit the form and do whatever you like to it.
#6
James Gregory
923 days ago
You got me there. The only examples I can think of would be considered bad practice anyway… Nevermind.

It’s still a bug though, doesn’t hurt to know about it.

Maybe i’ll start using it, now that my preconceptions have been dashed. ;)
#7
draco
922 days ago
@Matthew: Remember the shopping cart scriptlet you posted awhile back with the ‘update cart’ button? I implemented a new ‘confirm orders’ sort of button in the same form that finalises the items after clicking. And button sort of screwed up in IE, badly and so I was back to using inputs.

That way I have 2 submits in a form. Is that considered bad practices? How else would one do it otherwise?
#8
Matthew Pennell
921 days ago
draco: I personally don’t use two submits on a form due to the unpredictability of the results – a form should only be able to be submitted in one distinct way.

I’m not sure whether the way you are doing it (using the name attribute on the submit button to control what happens when the form is submitted) is the best way to do it. Especially for something like a shopping cart, where the contents aren’t really part of the form but are held in a database or the session.
#9
Krzychu Danek
921 days ago
I usually use more than one submit button on multipage forms for the previous / next action, so that users don’t have to fill in some fields again.

It can get messy if the fields in different steps depend on each other but it works quite well in most cases.
#10
Gratis Kontaktanzeige
920 days ago
Does the short in the Button actually work. I mean is it like the typical windows ALT + R for refresh ?
#11
Faruk Ates
919 days ago
I actually prefer the class=”input” approach on the Text input fields, because otherwise you also hit the input type=”checkbox” fields, which tends to cause side-effects in IE.
#12
Matthew Pennell
919 days ago
You start to tend dangerously towards ‘classitis’ there though, Faruk – IME most forms have a lot more text fields than radio buttons or checkboxes, so I usually class those (or their enclosing LABEL, really) rather than the text inputs.
#13
James AkaXakA
918 days ago
And by just targeting input’s inside labels, you wouldn’t even need to class them seperately!
#14