- Avoid too large tables
- Avoid table align="left" (or "right" )
- Positioning the submit button
- Using table header cells
- Tuning the visual appearance
Tables, forms, and nesting them
Tables and forms are separate concepts in HTML. People sometimes confuse them with each other. The conceptual confusion is often accompanied with confused markup. On the other hand, tables and forms can be "mixed" in a sense. Specifically, you can put a table inside a form or vice versa, and it is often useful to do so. But you need to understand what you are doing.
Tables and forms can be nested either way. But if you put forms into tables , each form must be completely included into a single table cell (one TD element in practice). Thereby the forms are each completely independent. See my document on choices in HTML forms for some simple examples.
What people probably want to do more often is to nest them the other way: a TABLE element inside a FORM element. Then all form fields within the table cells, being in TR elements within the TABLE element which is within the FORM element, are fields of the same form.
Should tables be used to structurize forms?
Whether it is useful to put the fields of a form into a table (within the FORM element) really depends on the form. For some odd reason, people who design HTML forms are often stuck with ideas of how forms are designed for paper. They put several unrelated questions to one row as if it were important to save paper. As a result, forms become harder to fill, since the intended order of filling it is not obvious. Rowwise or columnwise? Users may even fail to notice some questions. And having created a confused order, authors start wondering how to define tabbing order and things like that.
It is best to organize forms simply: don't use tables to force some particular layout but to indicate the structure when needed. Browsers are expected to present tables, and HTML documents in general, in a manner which corresponds to the structure expressed in HTML.
To take a fairly common example: Assume that you wish to let the user pick up a product from a list in and order form. Probably the product information consists of some fields like product name, order number, and unit price for each product. This means that the data itself is inherently tabular. Why not make it table? That would make the appearance reflect the structure. There are some technicalities involved here; see notes on using checkboxes or radio buttons (instead of SELECT ) for such purposes.
An example
As a simple example, consider the situation where some text (field label or something like that) is associated with an input field. (There are better ways for doing that in principle in HTML 4.0, but currently the table idea might be better.) You could set up a table where the first column contains the texts and the second column contains the corresponding input fields:
Your name Your E-mail address
On your current browser with its current settings, this would appear as follows:
The presentation can be affected by style sheets. In particular, this document comes with a style sheet which makes some presentational suggestions, so presentation may differ from your browser's usual way of displaying forms. See the document Affecting the presentation of form fields on Web pages .
Another typical case for using a table is to organize a set of radio buttons. There is an example of this in Choices in HTML forms as well as at the end of the current document.
Notes
Avoid too large tables
Although this method can be used for a form with a large number of fields, a practical word of warning is in order: the larger a table is, the longer it takes from a browser to display it. (The browser has to process the entire table before displaying anything of it, since it must take all cells into account when selecting suitable column widths.) Perhaps you can divide the content of a form into major sections, with headings, and structurize each section separately as a small table.
Due to a Netscape bug, it is best to avoid using the align="left" attribute for a table containing form fields. The reason is that Netscape seems to skip forms fields inside such tables in the tabbing order! ( is the order in which a browser traverses form fields and links on a page when the user presses the TAB key. It is an important useability and accessibility factor.)
Using table align="right" has similar effect.
With align="center" the situation seems to be different, but such attributes, as well as markup, have varying effects on different browsers. The effects may even depend on the DOCTYPE declaration! Since centering tables properly using a style sheet does not work well on current browsers, it's perhaps best to avoid attempts to center tables. Maybe it is sufficient to suggest just some reasonable left margin, using a style sheet.
Positioning the submit button
Notice that in our example the submit button is outside the table. The reason is that it has a different role than the other fields. It could be within the table too, but perhaps it is easier to find if it isn't.
Also notice that contrary to popular belief among authors, a reset button is not obligatory or even useful, as a rule. It is especially dangerous when presented alongside with a submit button!
Using table header cells
Our example uses the TD (table data cell) element markup for all cells, both those containing form fields and those containing titles for fields. It might be more logical to regard the latter as headings and use the TH (table heading cell) markup. For example:
Your name
A typical presentation of TH elements uses more emphatic style than for TD cells, e.g. by using bold face. Moreover, by default the content of a heading cell is centered whereas normal cells are left-aligned; this can be affected by using the ALIGN attribute if desired. The following shows how your browser displays (perhaps affected by a style sheet suggested in this document) our sample form when TH markup is used for the texts which are logically field titles:
Tuning the visual appearance
- differences between browsers and browser settings
- basic HTML markup, such as th vs. td (see above)
- attributes in table-related tags, such as cellpadding and cellspacing in a table tag and align and valign attributes in td and th tags
- attributes in form markup (e.g. the size attribute in input tags; note that the width of an input box is also affected by the font in use, perhaps in a surprising way)
- style sheets, which can be used in quite a few ways, but often with unwanted effects too, due to browser bugs.
The document Affecting the presentation of form fields on Web pages discusses the form-related issues in some details. For tables, see section on tables in my material on HTML 3.2 for basics, and e.g. section Tables in Mikodocs for more advanced issues.
As regards to issues specific to the combination of tables and forms, note that if you put a form into a table cell, then you there might be some unwanted extra vertical space below the form. There are various ways to try to suppress that. If there is only one form in the table, one of the ways is to change the structure so that the form and the table are nested the other way around: the form contains the table, even though only one cell contains fields of the form. Technically you'd just move the start and end tags of the form. This means something like the following (in a case where the form appears in the last cell of the table):
| . | . | .|
| . | . | .|
| . | . | .. |
. . .. . . .. . ..
The modified markup may look illogical, since structurally there is no need to have all the stuff in the other cells inside the form. But it can be done in valid HTML and with well-defined meaning: when the form is submitted, only the form fields matter, so the other content in the form has no effect on how form submission works. And since the (probable) extra spacing after a form appears only after the entire table, the presentational problem is removed, or at least made less important.
There are, however, the following problems with this approach, where the form element contains much more than what logically constitutes a form: A visual browser might have (e.g., due to a user style sheet) a special presentation for a form as a whole, e.g. using a distinctive background color or image to make the structure clear. When the markup is illogical, the user will be confused. Similarly, a speech-based user agent probably indicates the start of a form by saying, for example, "start of form 1". This is confusing, if the actual start of the form is far ahead.
An alternative: using just line breaks
Of course, you could dispense with tables within forms. You could simply write e.g.
Your name: Your E-mail address:On your current browser with its current settings, this would appear as follows:
The BR elements cause line breaks. It is largely a matter of taste whether you prefer this style to using tables. The main difference in typical presentation is that when using a table, the input fields "line up" forming a column. And style sheets or presentational attributes in table-related elements could be used to suggest the details of the presentation.
Another alternative: using paragraphs
You could also make each pair of field title and field element into a separate paragraph, a P element, e.g.
Your name: Your E-mail address: On your current browser with its current settings, this would appear as follows:
Although some people might say this would be waste of space, the use of some empty vertical space (as caused by browsers' way of presenting paragraphs) isn't really wasteful.
But since it might be argued that a field name and a field do not constitute a paragraph, you could alternatively use DIV elements instead of P elements. This would introduce no extra vertical spacing.
Yet another alternative: FIELDSET
One way of structuring a form is the FIELDSET element.
The following shows the presentation of the form on your current browser (on the left) and on IE 4 (on the right):
It is also possible to combine the use of FIELDSET with the use of a table to structurize e.g. a set of radio buttons. For radio buttons, and for checkboxes, the conventional method is to put the associated text after the radio button or checkbox. This is somewhat illogical but so common that accessibility tools might handle it better than the logical order. Example:
This results in the following presentation on your current browser:
It would perhaps be better (in cases like this at least, when there is a small number of alternatives) if the legend (which is logically a heading for the set of radio buttons) appeared at the same line as the alternatives. But the syntax of FIELDSET makes this impossible: the first element there must be LEGEND , so one cannot organize the legend and the buttons with their labels as one row in a table.
For accessibility reasons, and for clarity, it would be better to make each alternative appear on a line (row) of its own, using the same approach as above but a one-column table instead of a one-row table. Example:
In this approach, on the other hand, the table markup is rather unnecessary. You could just wrap each LABEL element inside a DIV element.
Using CSS to create tabular look
I have often argued that such a construct is a structural table (tabular data), not a layout table. It expresses the two-dimensional structure of the data in the form, including input fields. But many people disagree. Anyway, let's consider how you could achieve tabular layout for a form without using a table.
There are different approaches, but a simple one is like this: In HTML, inside a form element, use something like
etc.
This works without CSS, though not with a nice layout. For the layout, you could use CSS to suggest a common width for the label elements. This is guesswork to some extent, since you'd like to have width that is sufficient for all labels, but not wider than needed. Example:
labelThis is how it looks like on your browser:
Date of last update: 2011-12-15.This page belongs to division Web authoring and surfing , subdivision Forms in the free information site IT and communication by Jukka "Yucca" Korpela .
