If you are a Web designer or developer, you know that styling forms with CSS is a huge pain. Not only are browser inconsistencies rampant in form elements, but it is very difficult to get an advanced form to layout correctly, both visually & semantically. To alleviate these issues and to help designers / developers avoid unwanted stress, I took a crack at developing “RMSforms”, a CSS forms framework. To apply it to your forms, simply download the RMSforms CSS Stylesheet, link to it from your HTML and apply the correct classes to the HTML structure described below and you will be on your way to creating complex CSS-based, tableless, flexible forms with ease.
RMSforms v0.5 was tested in IE6 – 7, Firefox 3 & Google Chrome. More testing is to come.
It is validated using XHTML STRICT doctype
“RMSforms”, CSS forms framework is based off a very simple HTML structure:
<ul class="form [modifier]">
<li><label class="[label modifier]"></label><input/></li>
The Beauty of the Un-ordered List
Un-ordered lists are a great tool for grouping form elements together because they make sense semantically and provide for the level of flexibility needed to style a form effectively.
In essence, a web-based form is a LIST of form fields with coresponding labels that are grouped together visualy based on their association to each other. In the HTML structure of RMSforms, the <ul> provides a container for the list of all related labels / form fields and the <li> provides a container for the grouping of the individual <label> / form field combinations. In more complex forms, a <label> can often times be used to distinguish not only just one <input>, but a "nested form" that has a series of labels / form fields. With the the <ul><li> structure, nesting a form is very easy.
Other CSS form techniques use <p> tags, <div> tags, and line breaks to group individual labels & form field combinations together. I think these grouping methods leave a lot to be desired as far as flexibility and semantics. In my opinion, line breaks should be avoided whenever possible, <p> tags should only be used when presenting a paragraph, and although <div> tags would work, your html code would get real sloppy in an advanced form.
In every web-based form there are two layout orientations that can be used to display the relationship between a <label> and it’s corresponding form field; horizontal or vertical. The same is true for the visual orientation of the <label> / form field groupings to one another. This simple concept is the basis for the class names being used within the “RMSforms” framework.
The allmighty “form” class
Each top-level form <ul> in the "RMSforms" html structure has a base class of “form” applied to it. This class establishes a basic visual relationship between the elements within the form, sets a background-color and provides some outer padding.
The Modifier Classes
The most important classes defined in the "RMSforms" stylesheet are the “form modifiers”. These are 3 letter classes that modify the visual relationship between the <li>, <label>, and <input> elements respectively.
The first letter in the modifier class names describes the orientation of the <LI> tags in the form <ul>, the second letter describes the orientation of the <LABEL> tags in he form <ul> and the third letter describes the orientation of the form fields within the form <ul>. The 3 letters that make up the modifier class names are “H”, “V” and “I”
- H = Horizonal Block
- V = Vertical Block
- I = Inline
A list of all the form modifier classes:
- vvv – Vertical <li>, Vertical <label>, Vertical form fields
- hvv – Horizontal <li>, Vertical <label>, Vertical form fields
- hii – Horizontal <li>, Inline <label>, Inline form fields
- hhh – Horizontal <li>, Horizontal <label>, Horizontal form fields
- vii – Vertical <li>, Inline <label>, Inline form fields
- vhh – Vertical <li>, Horizontal <label>, Horizontal form fields
The class “hvv” describes a form with <li> tags that are layed out horizontally and <label> tags which are vertical block elements that sit on top of vertical block form field tags.
<ul class=”form (default form class) hvv (form modifier)“></ul>
To view this example in html, take a look at the RMSforms example page
Often times, you may want the visual orientation between a <label> and form field tags to vary within a form. For example, if one of your labels in a “VHH” form has a lot of text in it, you may want it to sit on top of it’s corresponding form field rather than to the left of it. This is where the label modifiers come into play. Label modifiers are used to override the classes placed on the form <ul> and should be applied to <label> elements within a form. The exiting label modifiers are classes:“v” or “h”.
One of the advantages to this form framework is the ability to nest form <ul> tags without a problem. In many advanced forms, problems pop up when needing to incorporate multiple <label> / form field combinations within one grouping. Using the form modifier classes, simply nest a form <ul> with the appropriate modifier applied to it within an <li> and you’re all set.
Why Not Just Use Tables?
Ah, the great question. Why not just use tables? Wouldn’t be a lot easier? Yes it would, but, being a semantic Web design nut, I believe tables should only be used in html to describe tabular data. If your not too concerned with html semantics, it is a very plausible solution for the laying out forms.
Comments, Suggestions and Modifications Are More Than Welcome.
"RMSforms" CSS Forms framework is a work in progress. The goal of this project is to make form styling as simple as possible. There are probably many scenarios in that I didn’t account for, or bugs that I have not come across. If you have any questions, comments or ways to improve this framework please post them up or contact me directly. I look forward to hearing from you!
- Added “list-item modifier: inline” (line 125): Adding class=”inline” to any <li> in a form will convert all inputs and labels contained in that list-item to inline elements. This is helpful when you have a form where a group of form elements needs to be displayed horizontally within one list item of a form laid out vertically.
- Separated “theme styles” from the framework styles in the Examples / Reference Sheet : This was done so that no generic font or layout styles are contained in the framework, making it easier to implement.