views:

11978

answers:

11

I've come across a few examples recently that do things like:

<dl>
  <dt>Full Name:</dt>
  <dd><input type="text" name="fullname"></dd>
  <dt>Email Address:</dt>
  <dd><input type="text" name="email"></dd>
</dl>

for doing HTML forms. Why is that? What is the advantage over using tables?

+8  A: 

Definition lists have semantic meaning. They are for listing terms (<dt>) and their associated definitions (<dd>). Therefore in this case a <dl> portrays the semantic meaning of the content more accurately than a table.

spiralhead
Or less, since most forms are not asking for definitions of terms (while tables are generic tuple relationships).
David Dorward
+8  A: 

This is a subset of the issue of semantics vs formatting. A definition list says what they are, a list of related key/value attributes, but does not say how to display it. A table says more about layout and how to display the data then what the data inside is. It limits how the list can be formatted both by overspecifying the format and by underspecifying what it is.

HTML, historically, has mixed up semantics with formatting. Font tags and tables being the worst examples. The move to CSS for the formatting and the stripping of a lot of the pure formatting tags out of XHTML restores, somewhat, the separation of meaning from formatting. By separating formatting into CSS you can display the same HTML in many different ways reformatting it for a wide browser, a small mobile browser, printing, plain text, etc...

For enlightenment, visit the CSS Zen Garden.

Schwern
I would add, that it adds intent, relationship. Later, a search engine could consume this page and discover the above code and know it's all related.
Chuck Conway
+2  A: 

Part of the reason for using <dl> for marking up the form is that it is much easier to do fancy CSS layout tricks with a <dl> than a <table>. The other part is that it better reflects the semantics of the form (a list of label/field pairs) than a table would.

Ok, table hate is part of it too.

Theran
A: 

Sometimes, a definition list simply presents the information in the way that's desired, whilst a table does not. Personally, I would probably not use a definition list for a form, unless it suits the style of the site.

staticsan
+38  A: 

I guess it's up to you to determine the semantics, but in my opinion:

Rather than a definition list, form-related properties should be used.

<form>
  <label for="fullname">Full Name:</label>
  <input type="text" name="fullname" id="fullname">
  <label for="email">Email Address:</label>
  <input type="text" name="email" id="email">
</form>

The "for" attribute in the <label> tag should reference the "id" attribute of a <input> tag. Note that when labels are associated with fields, clicking the label will put the associated field in focus.

You can also use tags like <fieldset> to cluster sections of a form together and <legend> to caption a fieldset.

sjstrutt
You can also put the input inside the label
nickf
+1 for being the only person to suggest the logical way to do this. A "table" is generally not semantically accurate or very flexible from a layout perspective. A "definition list" is closer but still a bit of a stretch. But "inputs" and "labels"? That's exactly what the things are!
Chuck
For a lot of forms, I believe a table /may/ be semantically appropriate. Not in all instances though. And as Chuck said, tables are not very flexible from a layout perspective.If you're going to use tables for your form, make sure it is semantically appropriate and make sure to use labels, too.
sjstrutt
nickf: Yes, but it's more flexible to don't nest them, because you can then do label{display:block;} to get labels above fields, or label{clear:both;float:left;width:300px;} to get a tabular look.
svinto
svinto: your second example is the approach I´m normally using. The problem is that you´re limited in the width of your labels; adding a long label or increasing the text size can lead to unwanted results and that´s where the table solution actually is more flexible.
jeroen
Have you actually ever had to try and juggle the CSS for something like this? It's very difficult!
Joe Philllips
@d03boy: Yes, I have.
sjstrutt
see http://www.slideshare.net/AaronGustafson/learning-to-love-forms-web-directions-south-07
abernier
+3  A: 

In this case, labels and inputs are your semantic meaning and they stand on their own.

Imagine you had to read the web page, out load, to a blind person. You wouldn't say "Okay, I have a list of definitions here. The first term is 'name'." Instead, you'd probably say "Okay we have a form here and it looks like the there's a set of fields, the first input is labeled 'name'."

This is why the semantic web is important. It allows the content of the page to represent itself accurately to both humans and technology. For example, there are many browser plugins that help people quickly fill out web forms with their standard information (name, phone number, etc). These rarely work well if inputs don't have associated labels.

Hope that helps.

Jeremy Ricketts
+11  A: 

I've succesfully used the technique outlined in this article several times.

I agree with sjstrutt that you should use form reated tags like label and form in you forms, but the HTML outlined in his example, will often lack some code you can use as "hooks" for styling your form with CSS.

As a consequense of this I markup my forms like this:

<form name="LoginForm" action="thispage">
    <fieldset>
        <legend>Form header</legend>
        <ul>
            <li>
                <label for="UserName">Username: </label>
                <input id="UserName" name="UserName" type="text" />
            </li>
            <li>
                <label for="Password">Password: </label>
                <input id="Password" name="Password" type="text" />
            </li>
        </ul>
    </fieldset>
    <fieldset class="buttons">
        <input class="submit" type="submit" value="Login" />
    </fieldset>
</form>

This approach leaves me with a comprehensible set of tags, which contains enough hooks to style the forms in a lot of different ways.

Regards Jesper Hauge

Hauge
I markup my forms in exactly the same way.
Philip Morton
The only problem I have found with this approach is sometimes you need to put content in between 2 form elements which doesn't relate to either. Semantically, you should close the unordered list and start again, but then you may have a list consisting of only one child element.
alex
and what about checkbox list, where will u put it?
msony
+2  A: 

Definition lists are almost never used because semantically speaking they rarely show up on the internet.

In your case the correct code has been posted:

<form>
    <label for="fullname">Full Name:</label>
    <input type="text" name="fullname" id="fullname">
    <label for="email">Email Address:</label>
    <input type="text" name="email" id="email">
</form>

You are creating a form with inputs and labels for said inputs, you are not setting forth a list of words and defining them.

If you are doing some kind of help section then definition lists would be appropriate, e.g.:

<dl>
    <dt>HTML</dt>
    <dd>Hypertext Markup Language</dd>
    <dt>CSS</dt>
    <dd>Cascade Stylesheets</dd>
    <dt>PHP</dt>
    <dd>Hypertext Preprocessor</dd>
</dl>
Andrew G. Johnson
Term: First NameDefinition: Please supply one in the box provided.
J Wynia
Whaaaaaaaat...?
Andrew G. Johnson
Sorry. If you think of the term (the dt) as the things like "First Name", "Last Name", etc., the definition (the dd) can be seen as supplied by the user.
J Wynia
+2  A: 

Virtually all forms are tabular. Do you ever see a form that's not tabular? The guidelines I've read suggested using the table tag for tabular presentation and that's exactly what forms, calendars, and spreadsheets are for. And now they're using DD and DT instead of tables? What is the Web coming to?! :)

netrox
I think it's example ot tablephobia;) I've seen tabular data made of nested `<ul>` and `<ol>`'s styled with tons of CSS just because *tables are evil*.
el.pescado
+1  A: 

Using dl dt,dd for forms is just another way to structure your forms, along with ul li, div and table. You can always put a label into dt. This way you keep the form specific element label in place.

<form action="/login" method="post"> 
    <dl>
        <dt><label for="login">Login</label></dt>
        <dd><input type="text" name="login" id="login"/></dd>
        <dt><label for="password">Password</label></dt>
        <dd><input type="password" name="password" id="password"/></dd>  
        <dd><input type="submit" value="Add"/></dd>
    </dl>
</form>
ak
Your example is against the specification, as your submit button belongs to the password dt. You have multiple dd's belonging to a single dt, which is what you're doing here. I would put the submit button below the dl entirely, because the dl is only meant for name-value groups--not elements that stand on their own like a submit button.
sfjedi
I don't think it is against the specification. You may have as many descriptions per term as you want (and vice versa)http://www.w3.org/TR/html401/struct/lists.html#h-10.3But you are right, the submit button should be moved out of the Password definition.
ak
A: 

read each - ab fanily word in the first column. find the correct definition and write the matching lettler nex t to the word (see sample). write each word in a sentence.

aracely mendez