Please note: This site's design is only visible in a graphical browser that supports Web standards, but its content is accessible to any browser or Internet device. To see this site as it was designed please upgrade to a Web standards compliant browser.
 
Signal vs. Noise

Our book:
Defensive Design for the Web: How To Improve Error Messages, Help, Forms, and Other Crisis Points
Available Now ($16.99)

Most Popular (last 15 days)
Looking for old posts?
37signals Mailing List

Subscribe to our free newsletter and receive updates on 37signals' latest projects, research, announcements, and more (about one email per month).

37signals Services
Syndicate
XML version (full posts)
Get Firefox!

Using Definition Lists For Forms

22 Sep 2004 by Matthew Linderman

We’ve been getting some good mileage from coding forms using definition lists lately. Just place each form label inside a definition term tag (<dt>) followed by its associated form control wrapped in a definition description tag (<dd>). It’s a great way to keep form code clean and tableless. Dan Cederholm discusses the technique further at devarticles.com.

16 comments so far (Post a Comment)

22 Sep 2004 | waylman said...

Funny you should mention this, just this last weekend I was working on a few forms for my (hopfully) soon to be launched redesign and, before working out how to arrange the markup, viewed the source on Dan's site (and really, who else would you use to answer such a question?). Personally I thought the idea was brillient. Although, I will have to say that my forms look an awful lot like Dan's - but then again, I haven't finished that part yet.

22 Sep 2004 | Austin Govella said...

Cederholm mentions definition lists stretch the semantic purpose of definition lists, but using ordered or unordered lists avoids this snag.

Plus Cederholm's separation of label and form inputs (though valid) prevents a lot of useful form interaction in IE.

Lists are a better way to implement forms, but the form inputs need to be inside the label tags to account for IE bugginess.

Here's how I do it (angle brackets changed to square so it'll post):

[form]
[ol]
[li class="required"]
[hn] optional form element title [/hn]
[p] optional instructions for this element [/p]
[label] label (required): [input /] [/label]
[/li]
[/ol]
[/form]

If the data throws an error, the form display is altered with a semantically appropriate error message (notice the class changes from "required" to "error"):

[form]
[ol]
[li class="error"]
[hn] optional form element name [/hn]
[p] optional instructions for this element [/p]
[ol]
[li] first error message [li]
[li] second error message [li]
[/ol]
[label] label (required): [input /][/label]
[/li]
[/ol]
[/form]

I've been ordered using lists for a while now since they auto-number long online surveys, but (as illustrated above), I only have one publicly accessible example (the rest are inside an intranet):
* https://eto.uh.edu/register/

Newer forms now have a global error message at the top that explain we found some errors. Adding "error" to the form title seemed a little brusque.

Just my two cents.

22 Sep 2004 | Scott Plumlee said...

How about just using form, fieldset, legend, label, break tag, input, break tag, etc... The break tags let you separate the label and the input into two lines even when CSS is off, or you can leave them out if you want them to be on the same line. For multiple checkboxes, you can nest other fieldsets as needed to group things together and even use another legend to label all of them as a group. I have found that if you zero out the padding and margins on the labels and inputs, you then want to use vertical-align: middle to make them line up properly.

I like to idea of using dl's for things like images and captions, when you need to relate one item to another piece of info, I'm just not sure about this case. The break tag method adds less markup then the dl method so that might be another advantage.

Downside might be the 1 pixel border applioed to fieldsets when styles are off. Some people might like it, some not.

22 Sep 2004 | Blake Scarbrough said...

I prefer to keep the code a little lighter with just using tags like mentioned from Scott


How about just using form, fieldset, legend, label, break tag, input, break tag, etc...

This is what I have done and I think it works well. Transformers

22 Sep 2004 | Terrence Wood said...

It's a real shame that the label tag while being a block level element, in so far that it can contain other elements, doesn't render has a block element by default. That would make it so much easier to create good looking, usable forms without resorting to hacking the markup.

This definition list technique is interesting, but I'm going to stick with fieldset, legend, and label to give structure to my forms.

And while it is important to give consideration to how forms render sans-stylesheets the liklihood of that happening in the real world today is pretty marginal.

23 Sep 2004 | a said...

Dan's article is riddled with old school HTML, like font tags. Some of them actually damage the content itself. The sentence:

"Perhaps you've heard others tell you you should always add [label] tags to your forms"

Appears as:

"Perhaps you've heard others tell you you should always add tags to your forms"

23 Sep 2004 | ale said...

Hey Matthew you read my mind :)
I am right now working on a project that needed some fresh form tips.

Blake Scarbrough, your form looks just great! I didnīt knew fieldset...

What an incredible great post!

Do you have link to forms you consider great?

23 Sep 2004 | tiffany said...

"It's a real shame that the label tag while being a block level element, in so far that it can contain other elements, doesn't render has a block element by default. That would make it so much easier to create good looking, usable forms without resorting to hacking the markup."

If you want label to be rendered as a block-level element, just add label{display:block;} to your stylesheet. Minimal 'hacking' and it eliminates the need for
tags to force a line break (except if stylesheets are turned-off, of course).

As for Dan's technique, I'm a little bit uncomfortable with the semantics. Definition lists are supposed to be used for definitions.

I suppose using unordered or ordered lists is better if you argue that a form is "a list of fields." But I prefer to use HTML's fieldset, label, etc. Why muck up the markup for what is marginally better presentation without styles?

23 Sep 2004 | Stefan Seiz said...

I am also just using and associates. Works well and looks semanticaly clean to me.

23 Sep 2004 | Stefan Seiz said...

Oops, mt ate the enclosed html tag.


Above should have read:
I am also just using fieldset and associates. Works well and looks semanticaly clean to me.

23 Sep 2004 | ted said...

I actually like the idea of using DL for marking up forms. I think it makes absolute sense as well. Think about, what exactly is a DL? It relates a term to a definition, a fairly broad relation. An image with a caption works, right? But is an image really a term? Loosely it can be thought of it that way.

Now take the form. The term is "email" and the definition is whatever the user inputs. Same type of relationship, but this time the definition is variable in nature and I think that is the hangup for most people.

But regardless of this fact, styling forms is much easier. If you have a long form and want labels on the left and inputs on the right, a table used to the case and can actually still be used today, since it is semantically correct, it's just a table of terms and inputs by the user. But the DL simplifies this markup and increases the semantics, adding what the LABEL tag already does.

Creating a form is super easy now. Set your DT to float:left; width:100px; and voila, looks like a table, but it isn't. And still looks pretty good without CSS. Win, win situation.

23 Sep 2004 | Scott Plumlee said...

An image with a caption works, right? But is an image really a term? Loosely it can be thought of it that way.
I'm in total agreement with using DLs to mark up images and captions in this manner, because there is not a defined method for doing so in HTML. I love the way I can create an association between the two in that case. But there is a method for creating labels and inputs and associating the two (via the for attribute of the label and the id attribute of the input). So I think it makes better sense to use the tool designed for the job in this case. The DL method is not wrong in any way, but it seems to be a case of re-inventing the wheel.

23 Sep 2004 | ted said...

Hmm that is true. I guess it seems that the DL method is easier when working with CSS to make pretty forms. Unless you have some good tricks with just labels and inputs? Btw, I'm not against using labels at all. I still use them in the DT part.

26 Sep 2004 | Dan said...

The last time I checked a form label and element were not definition lists, and thus using Def Lists as your forms markup matrix offers nothing desireable over a table. Both methods make for equally poor semantics, and poor semantics are the only reason I ever hear people cite for getting your forms out of tables.

I can see how high volume sites (eg, yahoo) may benefit by this since less HTML gets sent out the door.

27 Sep 2004 | Scott Plumlee said...

Unless you have some good tricks with just labels and inputs?
Nothing fancy, just style them as you would anything else. I'd use a Moz browser and the DOM inspector to see the computed styles on a page with no styles first to see what the defaults are before you start, because there are some gotchas that you might not expect. Also, IE seems to inherit form styles into the child elements in my experience. See my first comment for a tip about styling checkboxes and labels. I did learn from joelonsoftware.com to declare a monospace font for my text inputs to make reading end editing a field easier. Might not look quite as nice but it does seem easier to edit form info.

20 Oct 2004 | Richard Rutter said...

As you say, using definition lists for forms are an extremely neat way of marking up a straight-forward form. The great thing about definition lists, with all the dl's, dt's and dd's is that there are plenty of hooks for scripting and styling.

For those interested in try out definition lists in forms for themselves, a year or so ago I wrote a short tutorial on styling forms marked up with a definition list.

Comments on this post are closed

 
Back to Top ^