By Peter Bell

The "Right" Way to Style Forms

Posted At : December 24, 2007 1:56 AM | Posted By : Peter Bell
Related Categories: Forms, CSS
What do you think it the right way to style forms? Div's, DL/DT/DD, ordered lists? If you had to recommend a default way to mark up your forms, which approach would you recommend and why?

Comments (12) | Print | del.icio.us | Linking Blogs
Comments
[Add Comment]
I prefer the style you mentioned in the last post about this. Basic label tags within a div like this:

[div id="if_required" class="if_needed"]
[label for="always"]Some Label[/label]
[input id="always" /]
[/div]

Usually this'll mean floating the label tag, but if you want them on separate lines that's easy enough too. Can always add a ":" after the label if you want with css as well (for people past ie6).

Using a dl/dt/dd doesn't seem semantic enough, although a ul/ol does. Lists seem like a good way of doing it, but I've always shied away from them due to the ease and flexibility of using plain old div tags.
# Posted By Adam Fortuna | 12/24/07 7:26 AM
I agree with Adam,

I used to favour the DL method and I'll still use it if I work on a mobile site. It is the fewest characters, after all.

If you are starting from scratch, go as semantic as possible. All the cool kids are doing it. :)

DW
# Posted By Dan Wilson | 12/24/07 7:57 AM
I prefer just to use divs... one wrapped around each form element... that way you can use inheritance in your CSS to change the way the labels appear for a textarea vs. a text input.
# Posted By Russ Johnson | 12/24/07 11:22 AM
@Peter,

You should really check out the stuff that Javier Julio is doing with his form styling. When I was up at Arc90, he showed me some of it and it totally blew my mind! Talk about semantic markup!! He is light years beyond anything that I do with forms.

But, I think this begs the question: do you want to make better forms? or easier forms? From previous posts, it seems like your end goal is really to de-skill form creation. The problem is that there is certainly a threshhold for this; as you start to simplify forms and make the more semantic, they get easier to build. But then, you hit a point where the form becomes so clean and semantic that it requires a real in-depth thought about *what* is this form field and how does that affect its display. For example, FieldSet doesn't always apply, nor does label. Do you want someone pounding out these forms to have to make that decision?

I honestly think, as you go more to simple config patterns, you are going to have to start making compromises between what is the *right* way to do it and what is the *easy* way to do it.
# Posted By Ben Nadel | 12/24/07 11:44 AM
Just as a concrete example to Javier's form coding, he has the concept of Familiar and Unfamiliar (if memory serves me correctly). This is exactly what it sounds like - a familiar form has data that no one has to think about (birthday, name, email address, etc.) and an unfamiliar form has more unique data (maybe something like Favorite color of movie that first made you realize your mortal. The point is that by changing the form class from Familiar to Unfamiliar, the layout completely changes to make the type of data more accessible to the end user (via eye scanning studies and what not).

I bring that up, again, just to drive home the fact that as you get close to the *right* way to do things, the more skill is, in fact, needed to design and implement the form. Do you want a code monkey deciding how to craft the "user experience" for a given set of data?

I think, instead of searching for the "right" way to do this, you should be searching for the "best way to de-skill" form styling.
# Posted By Ben Nadel | 12/24/07 11:50 AM
You bring up a great point Ben! Well said! I didn't think about that before and you are right. Are we trying to make better forms or simply have them be easier to make? I've personally have tried finding the easiest way to make them while staying flexible when it comes to styling.

The thing you have to realize you can easily overdo semantics and make everything a list. It's simply to easy. I use them but on a form I don't feel they match. I feel a sort of division is in place so I use divs instead to lay out my forms. I've done a lot of tests on every possible markup: lists, definition lists, divs , floating divs, etc. So many options but when it all comes down to it I've found a simple div wrapper as the most cross browser and easy to style.

Web semantics are great and I support them but you have to be careful how far you take it. Yeah Ben you got it right on the dot! Familiar data is for data the user already knows: their name, address, email, etc. while unfamiliar data is for data that is application specific that the user might not know off their top of their head. For more reading on everything forms there is only one person to go too: LukeW (http://www.lukew.com/ff/entry.asp?502) Enjoy!
# Posted By Javier Julio | 12/24/07 12:18 PM
Thanks everyone! Ben, great point - I am indeed looking to make forms "good enough" while still being very easy. I was tempted by div's, but wanted to get a few opinions to see if there were going to be a bunch of "you can't do that, it's not semantic" responses!

Sound to me like the div's have it, and as per previous posting, I won't really be hand coding this for every field, so if one day the semantic markup police decide all of the forms should be ordered lists, it won't be *too* hard to refactor.

Thanks everyone!
# Posted By Peter Bell | 12/24/07 3:27 PM
It depends on the form.

When a lot of web designers talk about forms, they mean the "Address Entry From", which is pretty much ubiquitous. These forms usually don't have more than 20-25 fields in them. For forms like that, a [div class="formItem"][label for="name"]Name:[/label][input type="text" name="foo" id="foo"][/div] style form is usually sufficient.

However, in my job, we usually end up creating forms with 50 on up to several hundred item forms, which our user community demands must all be editable at the same time, because they're used to filling out paper forms, or editing Excel or Word forms. In these cases, we end up using tables to pack the information onto the screen in a grid:

[table class="inputForm"]
[tr]
[th colspan="4" class="subhead"]Problem Report Form[/th]
[/tr]
[tr]
[th]Originator[/th]
[th]Component[/th]
[th]Problem Type[/th]
[th]Priority[/th]
[/tr]
[tr]
[td][input type="text" name="originator" id="originator"][/td]
etc....
[/tr]
# Posted By Adam Ness | 12/25/07 10:16 AM
Hi Adam,

Good point as that isn't a use case I have to deal with. As a side note, you *could* use css for the grid of form fields if you wanted - although complex layouts might be tricker to style. I might also consider tabbed divs for breaking up the fields between screens without requiring the user to do a round trip to the server as a compromise if you really have a lot of fields, but obviously if they want to see all the fields on one screen that wouldn't fly . . .
# Posted By Peter Bell | 12/25/07 4:22 PM
Hi Peter,

I found that uni-form (http://dnevnikeklektika.com/uni-form/) is a pretty good attempt at standardizing form markup. Of course, it hasn't become a standard but it does consolidate many of the techniques I've been using lately.
# Posted By Christian Ready | 12/26/07 11:44 AM
Hi Christian,

Nice link - thanks!
# Posted By Peter Bell | 12/26/07 5:42 PM
Manually typing out class names gets tedious after a while. My method is to use Lists, and H1-H6 hotkeys to add style. For example:

[DIV class="myClass"]
[UL]
[LI][H1]Title[/H1][/LI]
[LI][H2]Subject[/H2][/LI]
[LI][H3]Regular[/H3][/LI]
[LI][H4]Highlight[/H4][/LI]
[LI][H5]Help[/H5][/LI]
[LI][H6]Special[/H6][/LI]
[/UL]
[/DIV]

The benefit of the above method: Every WYSIWYG has buttons for creating UL/OL lists, so it's easy to click that control, and type out a list. The enter key automatically creates a new line. When you're done typing, simply click on the appropriate line, and press an H1-H6 hotkey to add style.

The name of the class is usually irrelevant. It is easier to refer to content by where it falls within a table. "Title/Subject/Regular" or "Header/Center/Footer" naming convention can be paired with a class in so many ways, and it saves you from having to memorize an infinate number of classes.
# Posted By Jeff Knooren | 2/10/08 6:33 AM
[Add Comment]
BlogCFC was created by Raymond Camden. This blog is running version 5.005.