Is it bad design to use table tags when displaying forms in html?

Question

I keep hearing that div tags should be used for layout purposes and not table tags. So does that also apply to form layout? I know a form layout is still a layout, but it seems like creating form layouts with divs requires more html and css. So with that in mind, should forms layouts use div tags instead?

Answer 1

Yes, it does apply for form layouts. Keep in mind that there are also tags like FIELDSET and LABEL which exist specifically for adding structure to a form, so it's not really a question of just using DIV. You should be able to markup a form with pretty minimal HTML, and let CSS do the rest of the work. E.g.:

<fieldset>
    <div>
         <label for="nameTextBox">Name:</label>
         <input id="nameTextBox" type="text" />
    </div>
    ...
</fieldset>

Answer 2

I think it's a myth that forms are "difficult" to layout nicely with good HTML and CSS. The level of control that CSS gives you over your layout goes way beyond what any clunky table-based layout ever would. This isn't a new idea, as this Smashing Magazine article from way back in 2006 shows.

I tend to use variants of the following markup in my forms. I have a generic .form style in my CSS and then variants for text inputs, checkboxes, selects, textareas etc etc.

.field label {
  float: left;
  width: 20%;
}

.field.text input {
  width: 75%;
  margin-left: 2%;
  padding: 3px;
}

<div class="field text">
  <label for="fieldName">Field Title</label>
  <input value="input value" type="text" name="fieldName" id="fieldName" />
</div>

Tables aren't evil. They are by far the best option when tabular data needs to be displayed. Forms IMHO aren't tabular data - they're forms, and CSS provides more than enough tools to layout forms however you like.

Answer 3

If you just need a simply row column grip type layout you shouldn't feel guilty using tables. I don't know how anyone can call that 'bad design' just because it's not CSS. I've seen many bad CSS based designs. I love CSS and think it far superior in many ways to traditional nested table layouts, but do what works bests and what is easiest to maintain and move onto more important, more impactful decisions.

Answer 4

The general principle is that you want to use whatever HTML elements best convey the semantic content that you are intending and then rely on css to visually represent that semantic content. Following that principle buys a lot of intrinsic benefits including easier site-general visual changes, search engine optimization, multi-device layouts, and accessibility.

So, the short answer is: you can do whatever you want, but best practices suggest that you only use table tags to represent tabular data and instead use whatever html tags best convey what it is that you are trying to represent. It might be a little harder initially, but once you get used to the idea, you'll wonder why you ever did it any other way.

Depending on what you are trying to do with your form, it shouldn't take that much more markup to use semantic markup and css, especially if you rely on the cascading properties of css. Also, if you have several of the same form across many pages in your site, the semantic approach is much more efficient, both to code and to maintain.

Answer 5

To make forms as accessible as possible and semantically correct, I use the following format:

  <fieldset>
  <ol>
    <li>
      <label for='text_field'>Text Field</label>
      <input type='text' name='text_field' id='text_field' />
    </li>
  </ol>
  </fieldset>

Answer 6

I use CSS mostly until CSS becomes a drag. For example it's a lot easier to create a 3+ column (3 sets of label + form field) form using a table than in css. I couldn't get the layout to look properly in all major browsers using pure css and I was spending too much time getting it to work. So I said screw it and I did it easily using a table. Table are not bad.

Answer 7

It's a grey area. Not everything in markup has clearly defined boundaries, and this is one case where you get to use your personal preference and make a judgement call. It doesn't quite fit the idea of data being organised, but the cells are related across multiple axes, and that's the rule of thumb I use to decide whether something fits in a table or not.

Answer 8

It's certainly easier to use table than div to layout a table, but keep in mind that a table is supposed to mean something - it's presenting data in a regular way for the user to see, more than putting boxes on the screen in a given order. Generally, I think forms layouts should use divs to decide how the form elements are displayed.

Answer 9

One thing that I don't often see discussed in these form layout questions, if you've chosen a table to layout your form (with labels on the left and fields on the right as mentioned in one of the answers) then that layout is fixed. At work we recently had to do a quick 'proof of concept' of our web apps in Arabic. The apps which had used tables for form layout were basically stuck, whereas I was able to reverse the order of all the form fields and labels on all my pages by changing about ten lines in my CSS file.

Answer 10

If your forms are laid out in a tabular format (for example, labels on the left and fields on the right), then yes, use table tags.

Answer 11

A form is not "presentation", you ask for data, you do not usually present data. I use a lot of inline editing in tabular data. Obviousely i use the datacells - td as holders for the input elements when switching from presentation to input.

Answer 12

Most of the answers I've seen here seem appropriate. The only thing I'd add, specifically to apathetic's or Mr. Matt's is to use <dl>/<dt>/<dd>. I believe these represent the list semantically.

<dl>
  <dt><label for="nameTextBox">Name:</label></dt>
  <dd><input value="input value" type="text" name="fieldName" id="fieldName" /></dd>
</dl>

You might want to restyle these, but this says semantically what's going on, that is you've got a list of "terms" (<dt>) and "definitions" (<dd>), with the term being the label and the definition being the user entered values.