Posts Tagged ‘css’

How to build a form – Part 2

Sunday, December 21st, 2008

Part two – labelling, messaging and moving those evil legends

At the end of part one we had a form which tasted a lot like 1994. It has controls with labels all inside fieldsets but looks pants. There are a few simple steps in tidying up.

Legends

Legends are notoriously difficult to style. So I don’t even try. I wrap each legend in a span and style the span. It really works. This is particulary important for legends which are eventually going to be the visual equivalents of labels. These are legends for mult control groups such as a set of radio buttons.

Label text and required markers.

If a field must be completed we should tell our users. This is often done using an asterisk. Why? I have an interesting alternative to the ubiquitous and meaningless asterisk. I use the word “required”. Weird I know, but hey, it works and is WYWIWYG (what you write is what you get). To get these required markers to work, and allow separate styles for the label, required marker and error messages, I wrap the label text in a span and the required marker in another span. I also use the label as the required marker for scripting the validation.

This is overkill but is based on a trick I picked up from The Man in Blue. We eventually have something that looks a bit like this:
<fieldset>
<legend><span>About you</span></legend>
<div>
<label for='firstnameField' class='required'>
<span class='labelText'>First name:
<span class='requiredmarker'>(required)</span>
</span>
<input type='text' name='firstname' id='firstnameField' value=''>
</label>
</div>
</fieldset>

So far all this has done is make a mess of the markup without improving the form. Bare with me – we will get there.

Design classes

We need to add a few classes to labels and controls to hang our CSS from. If every browser supported attribute selectors we could omit some of these, but we live in a less than perfect world.

I like to set all text controls to a common width. However, there are some times when this is inappropriate (date of birth fields for example). So we need a class to apply to inputs which will have this common width. We will be making labels display as blocks, so we will also need a class to put radio and checkbox labels back to inline.

So now I have a whole pile of excess markup but a form which is usable, accessible and very flexibly stylable. The CSS then becomes a lot of fun, but that is for another instalment

Example – for a more complete example see Amnesty’s membership form

<fieldset>
<legend><span>About you</span></legend>
<div class="controlSet">
<label for='firstnameField' class='required'>
<span class='labelText'>First name:
<span class='requiredmarker'>(required)</span>
</span>
<input type='text' name='firstname' id='firstnameField' class='input' value=''>
</label>
</div>
<fieldset>
<legend><span class="labelText required">Required grouping</span></legend>
<div class="controlSet">
<input type='checkbox' name='subscribe' id='subscribeField1' value='1'> <label for='subscribeField'>Label 1</label>
<input type='checkbox' name='subscribe' id='subscribeField2' value='1'> <label for='subscribeField'>Label 2</label>
<input type='checkbox' name='subscribe' id='subscribeField3' value='1'> <label for='subscribeField'>Label 3</label>
</div>
</fieldset>
</fieldset>

Forms – a standards based how-to, part 1

Sunday, December 21st, 2008

I had a phone conversation with Russ recently. He was surprised by a form on the Amnesty site. So I thought it might be worth an explanation.

Just so you know though, I am fundamentally a minimalist. I don’t like excessive design and excess mark up makes me quiver. I also think the mark up in these forms is a bit excessive.

Part one is about the markup of a form. I will base this on a rather complex example, that of Amnesty’s membership form. This is because this form has all my common building blocks in one form.

Basic controls

First of all, create your form and controls without any extraneous mark up. Text controls get wrapped in their labels, though I don’t do this with radios or checkboxen. I also place label text before the control except for radios and checkboxen where they go after the input.

Example 1: two fields with labels

<label for='nameField'>Label <input type='text' name='name' id='nameField' value=''></label>
<input type='checkbox' name='subscribe' id='subscribeField' value='1'> <label for='subscribeField'>Subscribe to our newsletter</label>

This is going to give you a form which is pretty much unusable as well as extremely ugly. The next step then is to break each control set (control and label) into separate lines. You could do this with CSS. However, this will result in a mangled mess for browsers withh CSS turned off. So here is my first bit of extraneous mark up. I wrap each control set in a div.

<div>
<label for='nameField'>Label <input type='text' name='name' id='nameField' value=''></label>
</div>
<div>
<input type='checkbox' name='subscribe' id='subscribeField' value='1'> <label for='subscribeField'>Subscribe to our newsletter</label>
</div>

The result of this is a long list of controls with no regularity of positioning of controls – still a bit of a mess but at least now a vaguely usable mess.

Joy of Sets

Each functional grouping in a form goes in a field set. There has to be a good reason to not use field sets, and forms which have more than one functional division really need them. What do I mean by functional division? A set of controls which map to a specific function or data set such as an addres set or credit card details. Grouped radio buttons or checkboxen also go in fieldsets. This breaks the form up into digestible chunks, provides a means for labelling parts of the form, and, with sets of radios/checkboxen, provides for a means of labelling the group as well as the individual items using the legend.

The fieldset should have a legend. I could rant for hours about legends. I really could. The legend is a cue to the purpose of that part of your form.

So we break the form up into sensible units and wrap each unit in a fieldset. I also use nested fieldsets where necessary. There are some issues with nested fieldsets and certain screen readers but they are more accessible than any other mechanism for labelling grouped radios.

What you have now is a more complex mess than before. Great if you can’t see but pretty horrible if you can.  This is the final form, functionality wise, however, so it is where part one ends.