Back in the dark ages of web markup, the most reliable way to layout anything was by using a table. One of the best utilization’s of the table-based layout was laying out a form. We’ve come a long way in breaking away from laying out forms in tables. There are plenty of techniques for doing this that have already been discussed, so I’m not going to rehash that. Some would even argue that tables are still the most reliable to layout forms.

There’s one aspect of table based layouts that has eluded the non-table based layouts. The magic of the table cell. Or more specifically, the magic of multiple table cells working in unison. If the width of one table cell expands, all the others in the column follow along. This is especially useful when it comes to laying out forms. When laying out a form with tables, one cell is defined as the form label and the adjacent cell is the actual form element. This is repeated down the table columns for additional form elements. Instead of having to explicitly define a width for the label cell, the form label widths can be defined by width of the cell with the longest text label. This helps keep the form elements and form labels properly aligned without having to define an explicit width for each individual form label.

When it comes to non-table based layouts, each element is independent of the other. If the text size in one form label is longer than the others, the other labels don’t care. They stay right where they are with their own defined width. To get the form labels and elements properly aligned, you need to explicitly define the width of all your labels. Which can be a totally acceptable solution if you know what the content of every form will be and how long the average form label will be. But when it comes to dynamic systems that may have a single form layout framework used for all forms throughout the system, you may never know what text is thrown into the form labels or how large the form may be. Leaving you’re explicitly defined form structure in a highly dynamic system to become inconsistent at times.

Two forms with explicitly defined widths with varying length text labels

So why go with the non-table based solution? Flexibility. The flexibility you have with your form layouts far outweigh this one issue. Want you’re labels to the left of your form element instead of the top? Or maybe on the right instead of the left? It’s a matter of just changing the CSS declarations related to the label. To do that with a table based structure, you need to restructure the table. And within dynamic systems that may have that form distributed through several files, you could be in for a lot of hurt in updating that table.

Which brings us back to the special magic of the table cell. For a long time it’s been defined in the CSS 2.1 specification that the “display” property could not only define the layout of an element as block or inline, you could also define it as table, table-row, table-cell and various other table properties. These table based display properties allow you to define other elements, such as divs, to take on the structural properties of these table elements. But support for these property values has been spotty or non-existent in most of the major browsers. But this will be changing with the upcoming crop of new browsers.

In trying to come up with optimal form layout markup for one of our clients at the Hive, I wanted to find a solution for the form label issue described above. The following is some sample markup of a simple form.

 <div class="myForm">
    <div class="row">
      <label for="text1">Label</label>
      <input type="text" name="text1" />
    </div>
    <div class="row">
      <label for="text3">Here's a super long label</label>
      <input type="text" name="text3" />
    </div>
    <div class="row">
      <label for="text2">Another label</label>
      <input type="text" name="text2" />
    </div>
  </div>

The goal is for all the labels to be align flush right against the form elements, have both the form elements and labels aligned vertically, and have the overall form aligned to the left of the containing element. But I don’t want to assign a width to the label because due to the dynamic nature of the form, I won’t know what the length of the label text will be or how many elements may makeup the form on a given page. For example, if I define the label width as 200px and there’s only two form elements with the labels of First and Last, the form won’t be aligned flush left of the containing element due to the large label width and short text strings within it.

This is where the table based display properties come in handy. I’m able to layout my form using semantic markup, but I’m then able to define that semantic markup to use some of the layout qualities of a table. I’ve essentially defined a sudo table by declaring these table based values in the display properties of various CSS element declarations.

.myForm{
  display: table;
}
.row{
  display: table-row;
}
label{
  display: table-cell;
  text-align: right;
  padding: 0 5px 10px 0;
}

This works in Safari 3.1, Opera 9, Firefox 3 (RC 1) and the IE8 beta. The IE8 beta is a little flaky, but it’s an early beta and there’s still more work to do on the CSS front for IE. Firefox 2 support is partial and IE6/7 support is non-existent. So use of this technique will depend on which browsers you choose to support.

Is this a solution to be used every time you create a form? No, of course not. This may even be an edge case for most people as their forms may be pretty straight forward. But there often times I find myself with the need to have the actual text of the label define width of the form labels. As with all design decisions, it really depends on the context within which your using your form and the problem you’re trying to solve.

You can view example of this technique here