Semantically speaking, should we be using tables to lay out forms, or should we be using some other mark-up combined with CSS? Responding to this question, Drew McLellan comments on Russell Beattie’s Notebook: [via Simon Willison]
I’m comfortable using tables for forms. My point of view is that they are interactive tabular data.
If you mark up your labels in a th, your form controls in a td and stick them both in the same row, you can justifiably represent these name/value pairs as a table. But, of course, that’s not the end of the story. What if you don’t want your labels next to your form controls? My contact form, for example, has labels sitting above the form controls.
Because you’ve just decided that your name/value pairs can and should go in a table, you have inherently defined how your form should look. Forms engage the user directly – more so than any other part of a website – how they are presented is extremely important. So although one can justify laying out a form in a table, it’s simply not flexible enough. Which begs the question: what mark-up should we use instead?
What we really need is some block level mark-up (to be compliant with XHTML Strict) which meaningfully associates the form control with its preceding label. And I reckon HTML 2.0 provides just the thing.
Enter the little-used definition list. By placing the label in a dt (definition term) element and the form control in a dd (definition definition) element, we can meaningfully associate one with the other. Consider this simple example:
<dl>
<dt>Email:</dt>
<dd><input type="text" name="email" /></dd>
<dt>Name:</dt>
<dd><input type="text" name="name" /></dd>
</dl>If the side-by-side table layout is what you’re after, we can apply some simple styles, based upon Mark Newhouse’s superb ALA article, Practical CSS Layout.
FORM DT {
clear:both;
width:33%;
float:left;
text-align:right;
}
FORM DD {
float:left;
width:66%;
margin:0 0 0.5em 0.25em;
}There will be those of you out there who say you can’t use a definition list for a form – it’s not a list of definitions
. I would rebut with this: the HTML 4.01 specification says that a dl could be used for pairings other than definitions, citing a script (character/speech pair) as an example.
Using a dl is more flexible than tables, and lighter & more meaningful than divs or paragraphs. It’s what I’ll be using for all my forms in future. Update: Here’s a worked example.
Guy wrote:
I like the argument a lot. Makes sense to me. The best take on forms so far.
Tim Parkin wrote:
Is it such a problem using non columnar pairings in a table layout? In many papers I have written, tables have been used to layout data that is certainly not key, value pairs. For instance, a table in one paper showed a layout for a machine and below this a set of data for the machine depending on the MVA rating. Some variables were constant and hence were pulled out into a row above the main data tables, these were marked up with there labels above the values. Furthermore, there were some rotor lamination values that were recorded below each machine.
This was a complex layout but was most definitely a tabular layout. defn – “tabular” ... of data, consisting of or presented in columns OR tables : defn – “table”...a set of facts or figures systematically displayed, especially in columns. Note the ‘especially in columns’ this doesn’t say ‘only in columns’. I have had this discussion before and I personally think that tabular data, means data that is systematically displayed. A lot of people take tabular data to mean columnar data which it most obviously not.
In fact the origin of tabular is ‘written on tablets’ not sure of the relevance but the new market for touchscreen laptops could now mean tabular means anything on a Tablet PC.
Scrivs wrote:
Great idea for forms. Forms are one of the last big “hurdles” I believe for creating CSS layouts. Everyone wants the form to look “perfect” because it is very important to have the element placed a certain way. I like the idea of using definition lists to control the elements of a form and yet stay semantically correct. Great writeup.
Jeremy Keith wrote:
Don’t forget to include the <label> tag as well:
<dl>
<dt><label for=”email”>Email:</label></dt>
<dd><input type=”text” name=”email” id=”email” /></dd>
<dt><label for=”name”>Name:</label></dt>
<dd><input type=”text” name=”name” id=”name” /></dd>
</dl>
Rich wrote:
Jeremy – I thought that would be coming :-)
I just kept my example nice and simple to make that point. In reality, you are entirely correct and
labeltags should always be included to increase the accessibliity of the form.Bryce wrote:
Thanks for the insightful post. Recently, I’ve been constructing a form and I had to remind myself that tables are not inherently dirty… however, I do like the definition list solution since it is semantically more meaningful and also more versatile in terms of formatting.
My question is this: would this technique still be relevant for a form that is a table? For example, my form is a series of rows for editing entries in a database. Perhaps a hybrid of a tabular form coupled with a series of definition lists is what I should use … ?
Micah wrote:
I’m glad you posted this and that it’s getting more response than on Simon’s weblog. That said, I don’t agree with you. You summed up your argument as three points:
> Using a dl is more flexible than tables, and lighter & more meaningful than divs or paragraphs.
First off, dl is only “more flexible” because most browsers have a pretty set-in-stone default display layout for tables. Don’t like your table cells as cell? Use display:block or display:inline to change this. Remember that CSS controls presentation, and that you can redefine the layout of your page entirely by defining different styles.
Second, you say that definition lists are “lighter,” which in my mind means “semantically less meaningful.” Markup adds meaning to your document by giving it structure. As much as we want to save bandwidth, it shouldn’t be at the expense of meaningful markup.
The third point, I agree with 100%. Both tables and definition lists are more meaningful in the context of a form than paragraphs, or DIVs marked up with IDs and classes.
I pretty much gave my argument for tables in the comments of Simon’s post. I would revise the conclusion slightly in light of your argument by saying that definition lists are OK for marking up forms taking data pairs, but that tables are more structurally meaningful (due to the TR tag and COLSPAN attribute) and therefore have wider application.
In fact, as a challenge design a form using DLs that takes the names of three employees, two who are married to each other and one single, and also takes two phone numbers: one for the married couple, and one for the single employee. Presentationally, this can be done with DLs, by placing the single married phone number input box under, say, the first of the two married employees. But this would not be obvious from the markup. Using a table and the COLSPAN attribute would make it clear that the first phone number is shared by the married couple, ie the first two names. This complex form in fact requires a table to be structurally unambiguous.
DL
DT DD DD DD DT DD DD/DL
How do the DDs match up?
TABLE
TR TD TD TD /TR TR TD(2) TD /TR/TABLE
Ahh, more clear with the TD spanning two columns.
Phil Wilson wrote:
I like this post a lot. It’s a good look at an alternative method of presenting forms.
Nice one.
Lanny Heidbreder wrote:
Micah:
I’d like to see you do terribly much with this in IE6.
“Lighter” means “less code involved” here, I’m fairly certain.
This is a pretty far-fetched example, I think. When would you ever know enough about your users to have to design a form this way?
Now, to be sure, tables DO have a place in forms
a form I made recently uses tables for the radio buttons, where each one has both a term and a description associated with it. But even that is inside a <dd>.newsection
Tim,
The HTML specification isn’t overt on this point, but when you consider the elements it defines for tables, I’m not sure it agrees with you.
And Richard, I beg to differ with your second-to-last paragraph: Forms ARE, in fact, term/definition pairs! The label is the term, and you supply the definition
in YOUR casenewsection
newsection of that term in the form. :)
-LH
Micah Sittig wrote:
Good point, Lanny. Getting anything near-cutting-edge in IE 6 is near impossible without some pretty ugly hacks. As for <dl>s being less-code heavy, I dunno, that’s like skateboarding without a helmet because it’s uncomfortable. Really, even though you might not forsee the event, it may come in handy someday. Then again, you might say that using a table for forms is like skateboarding with a full suit of armor on, it really depends on other things.
I drew up a quick form to illustrate what I was talking about. I’m still thinking about my point (could you tell that I was also trying to convince myself with that last argument?).
As for tabular data, there is an email from the W3C archives that does a pretty good job of defining tables, in my opinion:
> How do you distinguish tables used for layout and those for tabular data?
> I think the distinction is when the row-column position has meaning.
Somewhere along the line, I heard tabular data defined as data that is both columnar and “row-ular”, ie data that would still make sense if you flipped the table rows-for-columns. That makes sense to me. I think Tim’s web page would have been better off if he broke it up into several tables. That fails the “mark-up heavy” test, but it would be more semantically correct (and Richard did start off his post with Semantically speaking).
Rich wrote:
I guess my post started off asking the question from a semantics point of view but I really wanted to introduce some practicality into the equation. I still believe that, for the majority forms, using a
dlis more practical (and equally meaningful) than using a table .If your form contains tabular data then by all means use a table (inside a
ddif you want to combine both schools of thought!). What I don’t really understand is why one would mark-up a table and then applydisplay:inlineto render said table in a non-tabular manner.To my mind all meaningful markup has an inherent degree of presentation. An
olgives a numbered sequence of items, aulgives a sequence of related items, atablegives a two dimensional matrix of cells. If one doesn’t require a two dimensional matrix of cells then perhaps it shouln’t be marked up as a table…toilet seat wrote:
Good point!~~Getting anything near-cutting-edge in IE 6 is near impossible without some pretty ugly hacks.
calin wrote:
nice read; old but not deprecated! I think in terms of plain html code that comes out, for big forms the css wins in terms of clarity. I also like this dl & dt & dd approach more than the div stuff, even if you use on this page in the “add a comment” divs:)
Wahi wrote:
y esto funciona?
Chad wrote:
A good idea. Thanks.
One complaint: “Beg the question” does not mean “suggest the question”.
See: http://en.wikipedia.org/wiki/Begging_the_question/
gleddy wrote:
really interesting article… was just looking into accessability in my forms and stumbled on to this.
I like this way of thinking and will give it a shot on my next build. Seems to make a lot of sense semantically.
Grant wrote:
I find it ironic that this page is not valid XHTML despite claiming so at the bottom of the page.
Rich wrote:
Grant – thanks for pointing out the invalidity of this page. Some unencoded ampersands in people’s comments – naughty me. The page does not actually claim to be valid – it merely provides a link to the W3 validator. That said I do intend the page to be valid – I’ll have to work on my blogging software.
Chuck Spidell wrote:
Note: These are the only tabless forms I have found to display correctly on Internet Explorer 5.2 (Mac). However, the submit button looks a little funky but degrades gracefully. Maninblue.com also has another method on forms but it does not work on IE 5.2 (mac). Thanks Richard!
Donn wrote:
I thought I would finally post to one of these CSS type sites and ask if I am the only one who has noticed that in Firefox (under Linux) they are really, really, really, really slow?
Oh, and the mouse-wheel stops working for scrolling them. (Not always though.)
Other pages are fine, but it seems these “blocks” sort of suck-in the scrollability of the mouse wheel, ‘ts weird.
Still, I like this site regardless, nice and clean.
Rick wrote:
Interesting ideas. There is actually a slight contradiction in W3C about this…
When describing tables is does say that they should not be used to format pages (http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.2.2)
When explaining about forms it directly gives as example of a form laid out using a table: this combined WCAG rule 5.4 makes me think that this is infact more a case of good practice.
“5.4 If a table is used for layout, do not use any structural markup for the purpose of visual formatting. [Priority 2]”
I believe that probably the best option is to avoid using tables at all costs.. as discussed, <dl> is a great formatter, however… I think that tables, when combined with suitable accessibilty is acceptable. (eg – tabindex, label, fieldset.. etc).
PS – sorry this is an immensly late post by someone you dont know… just a great article so far from you guys!
Rich wrote:
Rick – good points. As you say there is nothing wrong with using a table to lay out a form provided both form and table are marked-up adequately, especially with regard to
label.MissPixel wrote:
I’m convinced that the definition list is a correct way to display forms, but…
does anyone have any idea how to construct a definition list containing two columns?
KJ wrote:
Well, I understand the theory, and like the idea, but I guess I’m enough of a CSS noob that I can’t get this working, and it’s blowing chunks on my page. The floats are choking on other divs, and the <dd>s won’t go the the right of the <dt>s.
I love a page that shows a great new code idea, without a sample page where it is actually working….
Rich wrote:
KJ – OK just for you, I’ve added a worked example.
Peter Kruithof wrote:
Suppose you have multiple input fields that apply to the same definition, ie: a name which consists of a first name, last name and – sometimes – a middle name. You would use a number of <dd>’s in conjunction with one <dt>, as you are supposed to.
What happens, is your second and third input field not lining up with your first, due to the float: left; style. So <dd>’s should have float: right;. Works the same, and aligns better.
Furthermore, this technique allows you to specify a :hover style for your <dt>, which applies to the <dd>(’s):
dt:hover + dd { background-color: #e8e8e8; }
correct me if I’m wrong, but this should do the trick
Rich wrote:
Peter – that sounds sensible to me.