An interesting article on ParticleTree has prompted me to re-work my piece about forms in tables.
I’ll post it as soon as Nefarious Designs v3 goes live…
Have just launched Low Cost Airport Car Hire - a nice little car hire site that I’ve used as an experiment with ems. If you try putting your text size up or down, you’ll notice it resizes the whole site. This is a nice effect that I’ve better used in my day job on the new Rentokil Initial corporate site (don’t worry, I’ll let you know when that launches too).
Taking into account everything I’ve been experimenting with recently, and the fact that I’m currently creating a nice web standards CMS called Noob, I’ve also decided to rework this site. Version 3 of Nefarious Designs will have a better blog, a better portfolio and an all round better feel. I should also mention it will have kick-ass accessibility (since that’s my passion at the moment).
Basically, I want to sell myself as the hardcore web standards and accessibility developer that I already am.
Nefarious Designs is also going to be working much more closely with Muffin Research Labs and Source Unknown Designs as well, since it appears to be a mutually beneficial threesome. Fnar fnar.
Talking of AJAX; check out Google Suggest…
Also, I’ve decided to create my own PHP, XHTML, CSS, DOM scripting (including AJAX) sub site which I can use to develop ideas. Watch this space!
Having started to dabble with AJAX, I recently decided to start developing a generic form validation and database manipulation tool in PHP classes.
Anyway, whilst taking a break and trawling around the usual CSS showcase sites, I came across this little gem:
http://particletree.com/features/smart-validation-with-ajax
Nice idea: it’s kinda changed the way I’m approaching my problem.
Maybe I could do with a sandbox on my site…
Thanks to the wonders of XHTML and CSS, table based design is becoming a thing of the past. We’ve all discovered that, even though columns are easier to layout with tables, they damage our markup, annoy the search engines and play havoc with accessibility legislation. However, its also apparent that tables should be used in web sites to control tabulated data. But what defines tabulated data?
Let’s take a look at some good XHTML table markup:
<table cellspacing="0" id="toTableDemo1">
<thead>
<tr>
<th scope="col">Name</th>
<th scope="col">Bananas</th>
</tr>
</thead>
<tbody>
<tr>
<td>Tim</td>
<td>32</td>
</tr>
<tr>
<td>Paul</td>
<td>1</td>
</tr>
<tr>
<td>Stuart</td>
<td>100</td>
</tr>
<tr>
<td>Suzy</td>
<td>75</td>
</tr>
</tbody>
</table>
This would display the following (with a little help from CSS):
| Name | Bananas |
|---|---|
| Tim | 32 |
| Paul | 1 |
| Stuart | 100 |
| Suzy | 75 |
By incorporating a thead section we have defined a title for each column: making it easier to read for normal users and also for those using text readers.
Unfortunately, not all tabulated data can be presented in a way that allows us to clearly seperate the header, body and footer sections using the thead, tbody and tfoot tags. A good example of this would be tabulated data that requires a legend down both axis of the grid. This would be similar to a spreadsheet in design. Below is an example:
| Mon | Tue | Wed | Thu | Fri | Sat | Sun | |
|---|---|---|---|---|---|---|---|
| Tim | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Paul | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Stuart | 100 | 100 | 100 | 100 | 100 | 100 | 100 |
| Suzy | 100 | 34 | 3667 | 3 | 19 | 20 | 21 |
And the markup:
<table cellspacing="0" id="toTableDemo2">
<tr>
<th scope="col"> </th>
<th scope="col">Mon</th>
<th scope="col">Tue</th>
<th scope="col">Wed</th>
<th scope="col">Thu</th>
<th scope="col">Fri</th>
<th scope="col">Sat</th>
<th scope="col">Sun</th>
</tr>
<tr>
<th scope="row">Tim</th>
<td>1</td>
<td>2</td>
<td>3</td>
<td>4</td>
<td>5</td>
<td>6</td>
<td>7</td>
</tr>
<tr>
<th scope="row">Paul</th>
<td>7</td>
<td>6</td>
<td>5</td>
<td>4</td>
<td>3</td>
<td>2</td>
<td>1</td>
</tr>
<tr>
<th scope="row">Stuart</th>
<td>100</td>
<td>100</td>
<td>100</td>
<td>100</td>
<td>100</td>
<td>100</td>
<td>100</td>
</tr>
<tr>
<th scope="row">Suzy</th>
<td>100</td>
<td>34</td>
<td>3667</td>
<td>3</td>
<td>19</td>
<td>20</td>
<td>21</td>
</tr>
</table>
As you can see, I’ve defined the legends using the th tag. This method is less confusing than using the thead section in this particular instance.
Now that we have two examples of good table markup in XHTML, let’s think about the role of the table on an XHTML page. Functionally, the table makes the data easier to read, allowing us to follow the rows and columns easily and associate the values with the relevant headers. With the design, the table also allows us to make data more presentable, which also makes it easier to read. Ultimately then, the XHTML table is simply about data presentation.
So what have I been leading up to? Recently I was arranging an XHTML form for a client when I found myself looking at the presentation from a different angle. Normally I would try and arrange the form fields within labels, those labels in turn would then be arranged within fieldsets. I can then arrange the fieldsets, labels and fields using floats and absolute positioning in the CSS to cobble together a nice table-less design. Of course, in the old days, I would have slapped the whole lot in a table and not thought twice about it. These days, however, table based design is, as we discussed earlier, frowned apon. But in this context, is it really so bad?
Imagine we lay out our form like so (here’s the markup followed by what it would display):
<form>
<fieldset>
<table cellspacing="0" id="toTableDemo3">
<tr>
<th scope="row">
<label for="input1">Name:</label>
</th>
<td>
<input id="input1" name="input1" type="text"/>
</td>
</tr>
<tr>
<th scope="row">
<label for="input2">Rank:</label>
</th>
<td>
<input id="input2" name="input2" type="text"/>
</td>
</tr>
<tr>
<td colspan="2">
<input id="sub_form" name="sub_form"
type="submit" value="Submit"/>
</td>
</tr>
</table>
</fieldset>
</form>
As you can see, the labels are in th tags (because that is effectively what they are) and the inputs themselves are considered standard data - much the same as if you were entering data into a spreadsheet. This markup is not only logically valid but also allows us flexibility in design. However, I still find myself struggling to lay things out without using the table because something inside me feels dirty. Really dirty. And although I might like feeling dirty, the CSS Nazi in me is disgusted.
So what do you think? When laying out forms, are tables valid markup or nasty, dirty, filthy markup?
Edit: In reply to Stuart’s comment below, I have added the scope attribute to my th tags. This allows the browser or text reader to have a better understanding of the header.
Categories: