CHAPTER 5
FORMS
WEB STANDARDS SOLUTIONS
62
Interactivity has always been an integral part of the Web, letting the user and site com-
municate through the exchange of information. Forms allow us to collect input from users
in an organized, predetermined fashion, and have always been sort of an “anything goes”
area when building websites. For instance, we’ll discover that marking up a form can be
handled in approximately 10,000 different ways. OK, perhaps not that many, but there are
several options to consider as well as steps that we can take to ensure our forms are struc-
tured in a way that’ll benefit both the user and site owner.
What are our options when marking up
a form?
Let’s take a look at four different ways to mark up the same, simple form—all of which
achieve similar results. We’ll go over each method and talk about the pros and cons that
are involved.
Method A: Using a table
<form action="/path/to/script" method="post">
<table>
<tr>
<th>Name:</th>
<td><input type="text" name="name" /></td>
</tr>
<tr>
<th>Email:</th>
<td><input type="text" name="email" /></td>
</tr>
<tr>
<th>&nbsp;</th>
<td><input type="submit" value="submit" /></td>
</tr>
</table>
</form>
Tables have long been used to mark up forms, and because of that frequent use, seeing
forms laid out in this particular way has become familiar to us: right- aligned text labels in
the left column, left- aligned form controls in the right column. Using a simple, two- column
table is one of the easiest ways to achieve a usable form layout.
Some could argue that a table isn’t necessary, while others believe that forms could be
considered tabular data. We’re not going to argue either side, but instead state that using
a table is sometimes the best way to achieve certain form layouts—especially complex
forms that involve multiple controls like radio buttons, select boxes, and so forth. Relying
solely on CSS to control the layout of complex forms can be frustrating, and often involves
adding extraneous <span> and <div> elements, with more code bloat than that of a
table.
FORMS
63
5
Let’s take a look at Figure 5-1 to see how Method A would appear in a typical visual browser.
Figure 5‑1. Method A as rendered
in a browser
You can see that by using a table, the labels and form elements line up nicely. For such a
simple form, though, I would probably opt to avoid the table altogether in favor of some-
thing that requires less markup. Unless this particular layout is crucial to the visual design
of the form, using a table here isn’t necessary. There are also a few accessibility concerns
we could address—and we will, while looking over the next two methods.
Method B: Tableless, but cramped
<form action="/path/to/script" method="post">
<p>
Name: <input type="text" name="name" /><br />
Email: <input type="text" name="email" /><br />
<input type="submit" value="submit" />
</p>
</form>
Using a single paragraph and a few <br /> elements to separate the items is a passable
solution—but could visually render a bit on the cramped side. Figure 5-2 shows how this
would typically appear in a browser.
Figure 5‑2. Method B as rendered
in a browser
You can see that while we got away without using a table, it looks rather cramped and ugly.
We also run into the problem of the form controls not lining up perfectly, as seen in
Figure 5-2.
We could alleviate some of the crowding by adding some margins to the <input> elements
using CSS like this:
input {
margin: 6px 0;
}

Get Web Standards Solutions: The Markup and Style Handbook, Special Edition now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.