SimpleQuiz › Form(atting) › Conclusion

This was a tough one to wrap up. There are probably more acceptable possibilities with this question than with previous questions. A lot of great examples were brought to light regarding label and fieldset elements.

Notable Comments

Simon Willison:

…once I start working with forms I switch my focus from semantics to accessibility and usability.

Excellent point. It’s always good practice to ask yourself whether you’re being semantic for the sake of being semantic. Have I mentioned that I don’t like the actual word “semantic”? I don’t.


I don’t really consider a form label and text field a paragraph so that’s out.

This was echoed through the rest of the discussion as well. However, it just might give you better results in the nonstyled version (as opposed to using a
div or label or nothing).

And while using nothing might not appeal to you, MikeyC pointed out that it will not validate without a block-level element surrounding the label.

Which brings us to using fieldset, which Dave S. first suggested. The use of fieldset opened the floodgates on a host of great examples, and for simple small forms, fieldset and some CSS applied might be all you really need.

The use of fieldset was also argued a bit, back and forth. On one hand, you could see this as purely a presentational addition, and on the other hand you could quote the W3C:

The FIELDSET element allows authors to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible.

I like the sound of that.

You can’t talk about forms without talking about using table to format them. Paul G.:

… it ensures that labels and inputs maintain a logical visual order and layout when CSS is off

Certainly for larger forms, when you’re dealing with multiple controls, inputs, form fields, drop-downs, etc. — tables still seem like the best way to go. You could argue either way, whether a form is tabular data — but the truth is, styling a large form soley with CSS is not a simple task, and undoubtedly will not degrade nicely.

Summary (my take)

When it comes to marking up forms, I’ll take the following into account:

  • When marking up a small form with a few elements, I’ll use fieldset and CSS to style them — taking into account what the unstyled form will look like.
  • Tables still are not evil. For large forms, in order to make the form useable and organized, it’s hard to beat the simplicity of a table here. CSS techniques seem to be somewhat complicated in a place where a simple table would work all around.
  • In the past, I’ve used p tags to group label and matching input tags. I’m now divided on this method. For simple forms, it will ensure consistent formatting across browsers yet could be argued that it is not a paragraph of text.
  • Trying to semantically structure a form makes my head hurt.

See all quiz questions and discussions in chronological order.


  1. alex says:

    Amen! I banged my head against CSS for nearly a week trying to replace tables in some of the web-based applications I design. Tables still work best for complex forms (at least for now) and they even look the same across all browsers! :)

  2. Jai says:

    Tables for forms makes sense to me, because in many situations you are entering tabular data. How many forms end up in a database? It’s a lot, you can bet on it! I’m thiking that tables may even make semantic sense in conjunction with forms. That’s a bit to chew on and think about… Thoughts?

  3. Conan says:

    I do not agree that table is the best way to go for controlling the layout of complex forms. As you design your form, if a time comes when you think to yourself, “a table would make this easier,” you should entertain the notion that you’re designing your form badly. Split the form across several pages, or divide it up into smaller chunks on the same page, with clear divisions.
    There is also the issue of semantics. Unless your td‘s contain only form-fields, and your th‘s contain only their respective labels*, I do not think that you’d have a semantic and accessible solution. At least, you don’t if you assume the notion that just because the contents of a database shares some inherent meaning with an HTML table you can get away with structuring a form using them and still make sense at the markup-level.
    * – Nesting a label in a th could also be argued to be wasted markup, since they are both used for labelling.
    I think the best solution for marking-up a complex form is to try not to have one in the first place. It would be a rare occurence indeed for someone to write a form so complex that it simply cannot be broken down into smaller sub-forms, styled using code similar to that in ALA’s Practical CSS Layout article.

  4. Gabe da Silveira says:

    Sorry Conan, but I’m going to have to disagree with you on this one. If all forms were of the registration or comments variety then I maybe could swallow it. In other words, I think if it’s the type of form where you basically have to go linearly through the form from start to finish then your methods should be sufficient.
    The difficulty lies in forms that are more of the control panel type. You know like a search form or something where you want to layout several adjacent columns and specific horizontal and vertical alignments. Sure you can probably cobble something together with a number of divs and CSS positioning, but there comes a time when a table with it’s natural liquidity and alignment simplifies the markup and minimizes browser quirkiness.
    The real problem with table-based designs is when the tables infiltrate every part of the page and get in the way of the semantic flow of actual content. When tables are used to achieve all layout effects, we quickly end up with an unreadable quagmire.
    For a complex, frequently-used form things are different… Frequently the entire form fits in one table, and if you need to control over columns and rows, then TRs and TDs make semantical sense. At least as much as having 3 layers of nested DIVs all with custom CSS that ends up being much more cumbersome than the natural presentational logic associated with a table. Let’s not forget that we will always be stuck using DIVs as hooks for our presentational CSS, so it’s not as if HTML itself can ever be free of presentational encumbrances. Before using a table for a form, I don’t ask myself, “Is this semantically correct?”, I ask myself, “Is there a more semantically correct method that is reasonably cross-browser compatible?”
    For simple forms I think the answer is a resounding YES! But I don’t believe on principle that any form is better without tables.

  5. Conan, I have an example for you. This form is used by many people every day. Whether in this location or another installation of the Bugzilla software, the query form is accessible, intuitive, and user-friendly. In my opinion, the form is well-designed, as it packs a lot of functionality into a small amount of space. Can you redesign this form without using tables?

  6. Conan says:

    Oops, it’s been a while since I checked this thread. :D
    Scott > Yes, this form can be redesigned without using tables, and I do not think that it would need over-complicated nestings of div‘s to do it. Just looking at it briefly, there are about only five places where I think floated div‘s would be needed. I will have a go at redesigning the page when I have a spare moment next week sometime.

  7. Mike says:

    I’ve used unordered lists for, well, lists of <input type="radio"/> elements, with list-type: none. Seems “semantically correct” and renders well, albeit somewhat confusing if CSS is off (with the bullets and radio buttons competing for clickiness). <rant>I also always use label elements with radio buttons and checkboxes, as I can’t stand when I click on a label and nothing happens.</rant>

  8. Jules says:

    There have been discussions regarding the use of tables to format forms. One interesting answer was to imagine a completed form – the questions (label) and answers (various types of inputs) are tabular data.
    I too have struggled with positional CSS to create table-less forms and it is not easy. However, in browsers that support “display: table-row” and “display: table-cell” the layout becomes just as easy as using tables. In my opinion, when these two display options become better supported, then there will be much easier development of table-like structures without tables.

  9. Dave Cheslow, PhD says:

    Not to get too esoteric, but a TABLE is just a visual respresntation of three semantic concepts – COLUMN, ROW and CELL. Since EF Codd expanded those concepts with relational algebra, we have RELATIONS, ATTRIBUTES and TUPLES. Again, three semantic concepts… which happen to be displayable as a TABLE. All of us who work with relational databases know that there are many ways to display TUPLES and their relationships…. some representations are better than others, depending on the circumstances.
    From a purely abstract position (a position you cannot practically adopt today), there is no purpose for <table> tags in XHTML – not EVEN for so-called “tabular data.”
    My point is that the discussion of whether it is “good” or “bad” to use tables for form layout (or for any display layout) is simply establishing an arbitrary definition of what is a “valid” table and what is not. In fact, all tables are invalid markup because all tables infer a physical representation that may, or may not, exist semantically for the data at hand.
    Let’s push the envelope and use CSS whenever we can stand it, use tables when it gets too frustrating for us, and promote the advancement of CSS to include constructs like “display: table-row;” which don’t really solve the problem, but, at least, separate the markup from the represntation.

  10. Trying to semantically structure a form makes my head hurt.

  11. I just wrote about this topic and started looking for other thoughts…apparently I’m not the only one who thinks its semantically correct to build forms with tables.