Form Doubts

Hi,

Just yesterday I read few articles regarding form design, and had me thinking for a while now.

Is it best to use ul or dl for forms? I currently use ul and li’s, but my recent readings has me thinking whether I should switch to definition lists. Additionally, Is it best practice to enclose input within label, if so should I exclude “for” attribute?

Which is most semantic?

Thanks :slight_smile:

Yes, it turned out he didn’t really want a form form at all. But it still serves as a decent example, I think, of how you can tackle a relatively complex design using semantic markup and making it as accessible as possible.

I agree. But in this case it had to look as similar as possible to the printed original. And requirements like that do pop up ever once in a while, so learning to emulate such designs (maintaining semantics and accessibility) is a necessary skill for web professionals.

I did a complex form for someone a while back.

Have Mercy! I would say so :slight_smile:

I did a [thread=619847]complex form[/thread] for someone a while back. You can probably get some ideas from that one; it contains a bit of everything, more or less. :slight_smile:

as i said, i have all the respect for your work and knowledge. whenever i have a somewhat blurry understanding i know i can take your opinion and go with it, as it is carefully presented and accurate.

and your work on that form is an example of serious programming :award:

i’ve spotted same mistakes made by the HP: insufficient info, lack of preparation in understanding the problem in order to find a proper solution, using a paper model as an interface model.

my personal go on the matter (now that he has made up his mind :slight_smile: ) was to divide the solution: use computer interface standards for creating a proper (clear, simple) form (but that was not the case here, data was retrieved rather than based on input) and then create a report that will be also printed, based on tables. in this case, the report being destined for paper would not raise the same accessibility problems.

since the report was going to be the final (only) step, after the validation of the (nonexistent) form, which is only logic, that report/form was not to be solving a semantic/accessibility problem but a printing problem. the display of it on screen was unnecessary and redundant with a report/print preview.

@AutisticCuckoo That is one sick form! I wish my company did that type of thing. We typically just throw tables at it until it works:nono:

I’ve been wondering about this because I’ve seen too many times tables and paragraphs being used to lay out a form, which didn’t make sense to me. I thought about using div containers but I wasn’t sure if that was the proper way to lay out a form (I didn’t want divitis). I read a short article somewhere saying that lists and definition lists were the most semantic way of laying out a form, which made no sense to me.

I want to create a simple contact form for the portfolio site I’ve just started planning. It seems your method is the best, simplest and most semantic way of laying out a simple form like a contact form. Unless someone wants to give some advice? I have very little experience with creating forms.

Cheers. :slight_smile:

while i admire the skills and effort put in this form (i really do), looking also at the corrected requirement:

it seems to me like a perfect example for when to use tables in full. the first thing to do is to identify the right way to go :slight_smile:

it looks more of a report than a form, a report that displays complete data previously filled in a form. a form, in my opinion, would never have to be that complex. it’s destined to be filled and readability and clarity should be primary concerns, leaving aside validation, of course.

for many years i’ve build forms for desktop applications. and for many years i’ve done the same mistake: try to emulate the paper form in them. a mistake because users tend to be cautious around things on their screen that look and feel like the real thing, and often misunderstand the process of filling it up. the computer spectre sits above them, and as a programmer, i have to make it very simple and clear for the user. emulation of real paper forms adds to the confusion and requires extra useless codding. an advice for form building: make it easy and clear for the user and for you :slight_smile: a report is one thing, and a form is another thing entirely.

As noonnope has already pointed out, there is a perfectly useable container element for that, namely the fieldset element. Use it, that’s what it’s for.

I don’t know that either <ul> or <dl> is particularly semantic. I’ve always been quite happy using <div>…

If you have <label>Blurb <input></label> then you don’t need the ‘for’ attribute, but then you are potentially limiting your design possibilities. You can’t use <dl> or <table> to set it out (not that you should probably be using <table> anyway, although there are times when it’s right), and you can’t set a width on the <label>.

there are a few errors in my previous post, but these are not changing the point i’m making.

first, headings are block-like elements and dt element needs to have inline content. so,

<dt><h2>First header</h2></dt>

not good :blush:

<dt>First header</dt>

more like.

secondly, not an error but an inconsistency: some lis have closing tag, some don’t :blush:

i don’t know… it seems you’ve reached the wrong conclusion. AutisticCuckoo has pointed out pretty clear.

ul, ol, dl, lists in general, are not the solution for form layout, CSS or no CSS involved. nor are tables.

you have two big wrappers for input elements: the form element and the fieldset element. you can use for labeling the input elements that need labeling, the label element or other elements such as span.

you can also use in your layout the <br> element for when deciding where the label should be: on the left or above the input elements, or where to break a line, even when your CSS it’s not there, for reasons you can’t control. that way you’ll have a consistent layout with and without CSS.

using lists: ul, ol, dl adds visual features to your form such as bullets or indentation on the next line, features you’ll have to correct using CSS. also, using lists adds accessibility problems. using tables for layout in forms is the newbie’s choice.

in short: no lists :slight_smile: no tables :slight_smile:

your form, above all other content in your page, should be functional with or without CSS and/or JS. as such, CSS and JS are only to be used for progressive enhancement of your forms. if your form looks bad and acts wrong without CSS and/or JS you need to go back to the drawing board.

Why not just wrap it in the form element itself? As AutisticCuckoo already mentioned the BR would work nicely to clear any floats - if that is the layout you are after.

When I am after a form that has labels before an input I use:


<form action="" method="post" onSubmit="">
	<fieldset>
		<legend>Contact Form</legend>
		<label for="name">Name:</label>
		<input type="text" id="name" name="name" class="input-field">
		<br class="form-clear">
		<label for="email">Email:</label>
		<input type="text" id="email" name="email" class="input-field">
		<br class="form-clear">
		<label for="words">Message</label>
		<textarea id="words" name="words" class="input-field" rows="20" cols="20"></textarea>
		<br class="form-clear">
		<label for="submit">&nbsp;</label>
		<input type="submit" id="submit" value="Submit">
		<br class="form-clear">
	</fieldset>
</form>


/* Form Styles */
label, input.input-field, textarea.input-field {
	float: left;
	display: block;
	margin: 0 0 8px 0;
}
label {
	width: 100px;
	margin: 0 15px 0 5px;
	font: bold normal 1em/2 Geneva, Arial, Helvetica, sans-serif;
	vertical-align: top;
	text-align: right;
	color: #E6E6D1;
}
input.input-field {
	width: 417px;
}
textarea.input-field {
	width: 416px;
	height: 100px;
}
br.form-clear {
	clear: left;
}

It’s semantic enough, and easy to code…

EDIT: I guess I do use the fieldset too, but that is to break the form down into logical blocks. It can also make you forms fancy if you add a little JavaScript.

if the form element is to be presented in a visually complex way, lists are not the answer. when using them, you first need to “waste” some CSS to cancel their defaults. and when no CSS is used you have a visual discrepancy. and using lists for forms hurts accessibility.

semantics is using elements for their intended purpose. lists are not to present a list of fields in a form, fieldset is for that.

following this wrong way of thinking, you could use an ul for paragraphs in a section (or ol). after all, it’s an unordered (ordered) list of paragraphs. going further, dl would be used to describe sections, with dt for the section headers and dd for the uls containing lis for paragraphs in those sections :slight_smile:


<h1>First Section</h1>
<dl>

<dt><h2>First header</h2></dt>
<dd>
<ul>
<li><p>First paragraph
<li><p>Second paragraph
</ul>
</dd>

<dt><h2>Second header</h2></dt>
<dd>
<ul>
<li><p>First paragraph</li>
<li><p>Second paragraph</li>
</ul>
</dd>

</dl>

<h1>Second Section</h1>
<dl>

<dt><h2>First header</h2></dt>
<dd>
<ul>
<li><p>First paragraph
<li><p>Second paragraph
</ul>
</dd>

<dt><h2>Second header</h2></dt>
<dd>
<ul>
<li><p>First paragraph</li>
<li><p>Second paragraph</li>
</ul>
</dd>

</dl>

do you like this use of lists? it can be done, but…

as for individual containers, take your pick.

Yes avoiding lists or containers maybe good, but what if the form element is to be presented in a way that is much more visually complex. Then using some sort of containers for the form text and fields becomes a necessity, wouldn’t it?

Thanks guys, the input doubt cleared. :slight_smile:

Could anyone more shed some light on what’s the best way to properly layout form elements i.e. divs, unordered lists, or definition lists. I’m not particularly considering tables, but are form elements similar to tabular data? I guess not.

In few of the articles I read, they said that the input captions or titles (whatever you call them) are like definition term and the input fields are the definition and that it would make more sense to use definition lists for forms instead of tables, divs, or ul.

I’m warming up to the idea myself, but I want to learn from others’ opinion as well before I switch to definition lists.

if you wrap a form element in a label element, then it’s implied the label is for that element, no need for a for attribute.

you use the for attribute when you have more than one label per element, or don’t want to use the label element as a wrapper.

as far as the lists go, you can use them for forms, but semantics goes out the window.

I’m almost embarrassed to admit how many years went by before I began using definition lists in my work. Because of the nature of the content I write, now I almost never not use them.

Imagine the following as a definition list of SitePoint folks:

Autistic Cuckoo

design guru

cssExp

up-and-coming member

Black Max

stunningly handsome :stuck_out_tongue:

and so forth. (I didn’t post this to “educate” you on DLs, it’s obvious you know what they are. I put it in here for the folks who aren’t sure how they work.)

The easiest way to ascertain this is to imagine what the form would look like without CSS applied to it. If it makes sense with a bullet point before each label/input, then use a <ul>. If it makes better sense with the input below the label, and indented, then use a <dl>.

You can also imagine how it would be read out by a screen reader. If hearing ‘bullet’ or ‘item’ before each field would sound right, then use a <ul>. If hearing ‘equals’ between the label and the field would be better, then use a <dl>.

Very, very, very few forms are lists, though, so this question should only be relevant about once every 15 years or so.

W3C gave use the <br> element type for a reason.