Aaron Gustafson’s Learning to Love Forms presentation at WebVisions 2007 outlined many of the building blocks required to develop effective forms with a strong focus on valid and efficient XHTML and CSS code.
- Forms are a necessary evil. People tend to overcomplicate forms but they can be broken down into discreet components.
- Treat forms like any other piece of XHTML. Be aware of browser inconsistencies and make accommodations.
- Break complex forms down into components.
- Look for ways to provide richer semantic meaning.
- Don’t try to over complicate form designs.
XHTML & CSS considerations
- FORM element establishes a form.
- ACTION is the only required attribute and should always be a URI.
- METHOD defaults to “get”.
- NAME is depreciated, use ID instead.
- FIELDSET element is used to group related form controls. Can be nested.
- LEGEND element should be used to provide a caption for a FIELDSET.
- Containing Form controls can use a P or DIV. If you have a sequence of from fields, can use OL (ordered list). This allows for better layout control.
- INPUT is a basic input control.
- NAME vs. ID. NAME is for the back end. ID is for the front end. Keep IDs from conflicting by using “field name-form name” as ID.
- TEXTAREA: a multi-line text form control. Requires ROWS and COLS attributes.
- LABEL element provides a means of associating content with a form control. Implicit association wraps the form control and the text (allows you to style presentation). Explicit association uses LABEL’s FOR attribute to reference a form control.
- Buttons: trigger events in a form. Use either INPUT or BUTTON element. BUTTON is very flexible and provides more control.
- Set font size to 62.5% -drops base font size to 10 pixels across all browsers.
- LEGEND renders rendering very inconsistently in all browsers. Padding on bottom of it is respected consistently. Margin is often ignored.
- Can use cursor style on button to change to a pointer to indicate actions.
- Generated content: can use label:after to set type after labels.
- Buttons: INPUTs are by default rendered as UI widgets from OS –can’t be changed. BUTTON is rendered pretty consistently as a box. Can do image replacements and more styling. BUTTON can contain just about any element within it: P, UL, etc. In IE if have multiple buttons on the page, they all submit at once. As a result, need Javascript for multiple BUTTONs on a page to work.
- SELECT: allows selection of one or more OPTIONS. VALUE attribute is optional (contents are submitted by default).
- OPTGROUP: allows you to nest options in a SELECT element. Renders as indented list. Not valid to nest OPTGROUPS.
- Usually the width you want for a SELECT is 4 pixels wider then you want for a SELECT.
- Select Replacement can be used to style SELECT forms. Can use background images (need javascript enabled to make it work). Will be released as part of book later in year.
- FIELDSETs are a great way to organize radio or checkbox groups. Use LEGEND as question or statement. UL lists the possible responses. Use implicit association to style in IE6.
- Set background of radio buttons to transparent to avoid IE styling bug (colors background grey).
- To align labels with radios use position relative and about 2px of top-padding.
- LEGEND ignores WIDTH attributes. Can use a SPAN element within a LEGEND to set right size.
- Search forms are usually GET so they can be bookmark-able.
- LEGEND should be used instead of LABEL when referring to more then on field.
- Can hide labels from being displayed on the page by moving them off the page. This keeps things more accessible.
- Use CLASS names to define relationships between related content within forms.
- LABEL: can contain more then one input field.
- DD can be used to group related content within a form when one filed is the top-level selector.
- Implicit labels used for radios & check boxes. Provides ability to set width on inputs.
- Required form fields: can use ABBR element to label an asterix for indicating required form fields. Can use TITLE tool tip to provide a roll-over that explains form fields. ABBRs are mostly ignored by IE6.
- Help text: can be wrapped by an EM element. Using CSS can get help text to overlay the form field.
- Error messaging: want it to appear as soon as possible for people to notice it. Within LABEL use STRONG element. Should use plain text to describe errors and how to correct them. May also include anchor links to provide direct access to where errors occurred.
- Can use Javascript to remove error highlights when correct input is provided.