Is It Acceptable to Use Tables for Forms? or Is It Still More Correct to Use Divs

Is it acceptable to use tables for forms? Or is it still more correct to use divs?

Both are correct.

I preffer using some div/li, as that allows me to make some different layouts, but tables for forms are not frowned upon.

Actually, by default, Django gives you table formated forms.

Complicated form table vs div

I would go the div route. As long as you're careful of your widths when you apply floats, it's actually pretty straightforward to get the layouts to work properly in different screen resolutions.

Here are a few rules:

1. Set a max width on your form or your form's wrapper element. If you want to float elements on one row make sure their width's added together does not exceed this width.
2. If you are adding horizontal padding/margins to your floated elements remember that these add to the total width of the element.
3. Avoid mixing percentage widths with pixel padding and margins. Apply the percentage width to a parent element and the pixel padding/margins to a child element.
4. Use clearing elements between your rows of elements to keep everything in line.

As to the markup, you can use the form elements along with CSS to create a semantic structure:

<fieldset>
    <legend>Fieldset Title</legend>

    <label for="input1">Input 1:</label>
    <span><input type="text" id="input1" name="input1"/></span>
    <label for="input2">Input 2:</label>
    <span><input type="text" id="input2" name="input2"/></span>

    <br/>

    <label for="input3">Input 3:</label>
    <span><input type="text" id="input3" name="input3"/></span>
    <label for="input4">Input 4:</label>
    <span><input type="text" id="input4" name="input4"/></span>
</fieldset>

And the CSS:

fieldset {
    padding: 20px 0;
    width: 600px;
    margin: 0;
    border: 0;
}

legend {
    display: block;
    width: 100%;
    background: black;
    color: white;
}

label, span{
    float: left;
    width: 150px;
}

input {
    width: 120px;  
}

br {
    clear: both;  
}

You can see the result here.

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

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>

Why not use tables for layout in HTML?

I'm going to go through your arguments one after another and try to show the errors in them.

It's good to separate content from layout
But this is a fallacious argument; Cliché Thinking.

It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.

So what? Does my boss care? Do my users care?

Depends. Is your boss pointy-haired? Then he might not care. If she's competent, then she will care, because the users will.

Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.

The majority of professional web developers seem to oppose you^{[citation needed]}. That tables are in fact less maintainable should be obvious. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.

By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

Deeply nested <div>s are an anti-pattern just as table layouts. Good web designers don't need many of them. On the other hand, even such deep-nested divs don't have many of the problems of table layouts. In fact, they can even contribute to a semantic structure by logically dividing the content in parts.

Readability of the code
I think it's the other way around. Most people understand html, little understand css. It's simpler.

“Most people” don't matter. Professionals matter. For professionals, table layouts create many more problems than HTML + CSS. This is like saying I shouldn't use GVim or Emacs because Notepad is simpler for most people. Or that I shouldn't use LaTeX because MS Word is simpler for most people.

It's better for SEO not to use tables

I don't know if this is true and wouldn't use this as an argument but it would be logical. Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for. Users search for terms used in the page title or similarly prominent positions. It would therefore be logical to exclude tabular content from filtering and thus cutting the processing time (and costs!) by a large factor.

Tables are slower.
An extra tbody element has to be inserted. This is peanuts for modern web browsers.

The extra element has got nothing to do with tables being slower. On the other hand, the layout algorithm for tables is much harder, the browser often has to wait for the whole table to load before it can begin to layout the content. Additionally, caching of the layout won't work (CSS can easily be cached). All this has been mentioned before.

Show me some benchmarks where the use of a table significantly slows down a page.

Unfortunately, I don't have any benchmark data. I would be interested in it myself because it's right that this argument lacks a certain scientific rigour.

Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.

Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.

Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.

Tables instead of DIVs

The whole "Tables vs Divs" thing just barely misses the mark. It's not "table" or "div". It's about using semantic html.

Even the div tag plays only a small part in a well laid out page. Don't overuse it. You shouldn't need that many if you put your html together correctly. Things like lists, field sets, legends, labels, paragraphs, etc can replace much of what a div or span is often used to accomplish. Div should be used primarily when it makes sense to indicate a logical division, and only appropriated for extra layout when absolutely necessary. The same is true for table; use it when you have tabular data, but not otherwise.

Then you have a more semantic page and you don't need quite as many classes defined in your CSS; you can target the tags directly instead. Possibly most importantly, you have a page that will score much better with Google (anecdotally) than the equivalent table or div-heavy page. Most of all it will help you better connect with a portion of your audience.

So if we go back and look at it in terms of table vs div, it's my opinion that we've actually come to the point where div is over-used and table is under-used. Why? Because when you really think about it, there are a lot of things out there that fall into the category of "tabular data" that tend to be overlooked. Answers and comments on this very web page, for example. They consist of multiple records, each with the same set of fields. They're even stored in a sql server table, for crying out loud. This is the exact definition of tabular data. This means an html table tag would absolutely be a good semantic choice to layout something like the posts here on Stack Overflow. The same principle applies to many other things as well. It may not be a good idea to use a table tag to set up a three column layout, but it's certainly just fine to use it for grids and lists... except, of course, when you can actually use the ol or ul (list) tags.

div element instead of table?

a few reasons:

1) div is more semantically correct in most cases. people who code their sites in table structure aren't using tables for what they're made for, which is tabular data. divs represent a "division" or a section of the page, so putting items in divs is more correct.

2) divs are more flexible and easier to style and maintain. you don't have to write <table><tr><td>Text here</td></tr></table> every time you want to say something when you can just write <div>Text here</div> instead. you can add css hooks (ie, classes or elements) to both tables and divs, but with divs it is infinitely more flexible.

3) table structured sites are just plain ugly :)

Yet Another Divs vs Tables issue: Forms

What I usually do is :

<form>
 <label for="param_1">Param 1</label>
 <input id="param_1" name="param_1"><br />
 <label for="param_2">Param 2</label>
 <input id="param_2" name="param_2"><br />
</form>

and in a CSS :

label,input { display: block; float: left; margin-bottom: 1ex; }
input { width: 20em; }
label { text-align: right; width: 15em; padding-right: 2em; }
br { clear: left; }

Of course, you'll have to define the width according to your actual data :-)

• First, give label and input display: block, so that it can be assigned a size and be lined up.
• They both get float: left because Explorer does things a bit differently
• Format the label nicely
• hack the br so that there's a clear: left somewhere, and I remember that putting it on the label didn't work on some browser.

Plus, with the br you get a nice formatting even if the browser does not support CSS :-)

Is it correct to use DIV inside FORM?

It is totally fine .

The form will submit only its input type controls ( *also Textarea , Select , etc...).

You have nothing to worry about a div within a form.

---

Related Topics