Forms in HTML - a designer's nightmare Pt. 1 2006-10-10 19:41
It is a well known fact that forms in HTML aren’t exactly popular amongst designers working on the Web. The form elements themselves are quite rigid and let’s not talk about browser renderings and inconsistencies one encounters when trying to really pimp out a form. For instance (and to my knowledge) Safari refuses to apply more complex CSS onto form elements all together. Sometimes it’s a good thing – from a usability point of view – but a designer craves more than browser default styles.
The very first you need to know when laying out HTML forms is not to push it too hard. If you try something extreme that might work with some „regular” elements it’s likely that it will not look it’s best applied to form elements (due to aforementioned browser inconsistencies). Your (as a designer) best bet when taking on a form in HTML is putting your money on the grid and typography. They will make or brake the form – it’s that simple.
One other thing a designer must take most precious care of is the sheer usability of the form itself. People will need to use those you know, and most people don’t handle HTML forms in their everyday lives, ergo forms need to be both intuitive so the most inexperienced user knows what field to fill with what information and visually appealing to both Web savvy users who are bored to hell with same old looking forms, and to those poor inexperienced ones who encounter them for the first time. Talk about being between a rock and a hard place.
I guess forms are one of the things that require the designer to really be more than a graphic/visual designer. A lot of form design concerns usability and accessibility, although the latter one varies from project to project, depending on the form’s purpose.
HTML in forms
There are many ways to go around marking up a form. Some people use fieldset elements and legends, some prefer not to, some wrap labels and inputs in paragraphs – some think it is a sacrilege – some use divs instead. I think as long as you are making a decent amount of sense in your markup – it’s all good. If everything still makes sense with styles turned off – you know you are on a good path.
I have developed a habit to use fieldsets, and – depending on the situation – either wrap the form elements in „holders” or leave them just in their fieldsets depending on the design. For this example I have prepared I won’t be using fieldsets (* find out why), but stick around to see the techniques I wan’t to share with you that make our forms more agile and flexible.
Our Markup
For this example I have decided to use a real life example, an application form I have made for the Cinedans Film Festival.
So here is our basic unit of form elements – the text input:
<div class="formItemHolder">
<p class="note">
We will need this if we have to contact you about your entry but it will not appear on the website.
</p>
<p class="formCtrls">
<label for="name">Name *</label>
<input type="text" id="name" name="name" size="30" />
</p>
</div>
The textarea:
<div class="formItemHolder">
<p class="formCtrls">
<label for="address">Address *</label>
<textarea id="address" cols="47" rows="6"></textarea>
</p>
</div>
The select:
<div class="formItemHolder">
<p class="note">
We will need this if we have to contact you about your entry.
</p>
<p class="formCtrls">
<label for="yearProduced">Year It Was Produced</label>
<select id="yearProduced" name="yearProduced">
<option>Please Select a Year</option>
<option>2006</option>
<option>2005</option>
<option>2004</option>
<option>2003</option>
<option>2002</option>
</select>
</p>
</div>
Note that some examples don’t contain the note paragraph to illustrate that everything works and looks fine with or without them.
As you can see, we have a little „note” to go along the form controls used to explain the needed type of information, and this was listed as a requirement for the project, if it weren’t there things would be much simpler. Logically – it is located before the form fields themselves, because the user should be aware of them before he/she enters any information into the fields in a scenario when a graphical browser isn’t used, or the form is accessed from a mobile device not fully supporting CSS. The label precedes the input field also – for the same reasons.
Our CSS
So far so good. Let’s see how our styles might go, first we define our formItemHolder class:
.formItemHolder{
overflow:hidden;
width:690px;
padding:5px;
background:#f8f8f8;
border-top:2px solid #efefef;
margin:2px 0;
}
Now define the styles for it’s content – the two paragraphs holding the form elements (formCtrls) and the note:
.formItemHolder p.formCtrls{
float:left;
width:335px;
margin:0;
}
.formItemHolder p.note{
float:right;
width:335px;
margin:4px 0;
font-size:90%;
}
Now what we need to do is add some more finer styles for form elements – the label, input, textarea, select, and the button:
.formItemHolder label{
display:block;
margin:0 0 2px 0;
font-weight:bold;
}
.formItemHolder input,
.formItemHolder textarea{
display:block;
width:100%;
border:1px solid #ccc;
padding:2px 0;
}
.formItemHolder input:focus,
.formItemHolder textarea:focus{
border-color:#777;
}
.formItemHolder select{
display:block;
width:100%;
}
.formItemHolder button{
padding:4px 12px;
}
The CSS is pretty self explanatory, but we’ll just go quickly through it to make it clear what we were doing exactly. (I will comment only the rules essential to the layout of the form and form elements, avoiding ones used for aesthetics.)
First – since we are making use of floats – we have declared the overflow:hidden property for .formItemHolder in order to clear it’s floated content. Note also that some browsers need an explicitly declared dimension to go along with overflow:hidden in order to behave correctly. In IE it is due to it’s hasLayout – we have to trigger it with a dimension, or you can do it with a CSS3 property zoom:1 but that will make your style sheet non valid for the W3C CSS validator.
Now that we have defined our main „holder” we need to arrange it’s contained elements – the .note and .formCtrls. We do this with the aid of opposing floats by floating the .formCtrls to the left and the .note to the right. We are also giving them widths, and by that we aren’t concerned of the layout breaking due to unplanned content. The note can contain as much text as we want and it won’t interfere with the other form elements.
The next thing we did is declared display:block to the label, input, textarea and select elements so they would be in their own „rows”.
One of the things you might have noticed is that we aren’t using an <input type="submit" /> as a submit button, but the actual button element. I really don’t know why it is so uncommon when it makes life so much easier (read: no class="button" ugliness).
One other thing you might have noticed is that I have chosen not to add any custom styling to the form’s submit elements. Even though the button is much much more flexible for these styles – I simply prefer to leave submit elements’ styling to the browser. Sure they don’t look as good and appropriate in some occasions, but their purpose is surely retained and clear. I feel that usability is more important here than looks. Some people mask their submit buttons so much that even experienced users need to take a second look to know where to click.
Stay tuned for the second part of this article in which we will expand the usage of this form adding radio and check boxes into the picture as well as styling for errors in a usable and a logical and natural way.
I haven’t used fieldset and legend elements because of the lack of time I had to finish the project. As you might know there are a lot of inconsistencies with the renderings of the legend element in particular with IE, surely I would have to hack around to get the layout I wanted, and that was just not the luxury I could afford.
2006-10-10 19:41; No comments yet
