Dynamic50 Web Design and Development, Ruby on Rails Specialists in London and Oxford, UK

Hello there! My name is Simon and I’ve just recently joined Dynamic50 as the resident front-end man. As part of the initial work, I needed to generate a bunch of generic, good looking reusable interface elements, and that of course involves the dreaded HTML form. Now, forms are notoriously difficult to style well consistently across browsers, but when you add in the requirement for accessible, semantically correct (or at least arguably correct…) markup; then it all adds up to no small task.

The first port of call in the process is the markup- how best to structure our form elements in a semantically correct way, meaning no random peppering of <p>s, correct use of <label>s, <fieldset>s and all the fun bits that makeup the HTML form soup. Trawling through the web for suitable approaches I come across this article by Josh Lockhart from ‘New Media Campaigns’. His suggestion is to wrap our fun form elements in a definition list (<dl>). It is an interesting approach and not something that I had thought about. I do agree that there is ’some semantic truth to this scenario’ and so decided to see how far I could get with this in mind. Some other interesting/useful resources that I came across include Prettier Accessible Formsby Nick Rigby, Accessible HTML/XHTML FormsBy Ian Lloyd, Label Placement in FormsBy Matteo Penzo, and of course, the W3C Form reference

So our the general pattern for our form will go something like this: labels or descriptions of fields go in the definition term(<dt>), and the field itself in definition description (<dd>)

<form>
  <fieldset>
    <legend>Legend Name</legend>
    <dl>
      <dt><label /><dt>
      <dd><input /></dd>

      <dt><label /></dt>
      <dd><input /></dd>

      <dt>and so on</dt>
      <dd>for however many fields you need...</dd>
    </dl>
  </fieldset>
</form>

Now this works well with simple label/input pairs such as text fields, text areas and password, but what about radio buttons and checkboxes? We can’t really follow the exact same pattern with these. If we step back and think about the usage of such elements, we’ll find that they are normally used in groups or lists. The decision was then to use the dt without a label and then put our groups of checkboxes or radio buttons in a list within the dd, like so…

       ...
      <dt>Selection</dt>
      <dd>
        <ul>
	  <li><input type="radio" /><label /></li>
	  <li><input type="radio" /><label /></li>
	  <li><input type="radio" /><label /></li>
	  <li><input type="radio" /><label /></li>
        </ul>
      </dd>
     ...

Semantically- it’s not perfect, but it’s not too bad. We could wrap the <ul> in a <fieldset>, but it’s a bit kludgey and a bit redundant, as we are already saying that this list a definition.

So with these 2 patterns, we already have quite a flexible base build and style a form from. For added flexibility, it’s a good idea to add classes to our various form element matching their type. So for a

<input type="input" />

for example, we would do…

<input class="input" type="input" />

Now, a word about the styling. Different user environments have different interface standards- a <button> looks different on OS X than on Windows for example. Where possible, I tend to stick to these defaults, rather than to force a whole new interface model on the user. If we deviate too far from these ‘environmental defaults’, then I believe that the usability is affected. There are of course times when we will need to deviate from this; but for a generic form, the defaults will be just fine.

I haven’t done too much with the styling, mainly adjusting the spacing here and there. A interesting point from one the articles above suggested that the best way to position labels is to have them directly above the field, so I have carried that over on these styles. So after some additions, much adjusting and class assignment, we have a generic (and hopefully semantic) form