Forms Markup and CSS
This post was originally published on Nidahas.com, the personal website of Prabhath Sirisena, and later moved to this space. Comments and trackbacks have been removed for easy migration.
Any web designer who’s played around with xhtml and css long enough will admit that forms, perhaps after tables, are the biggest PITA in our trade. They manage to hurt the best of us, but so little seems to have been achieved on setting a proper standard for forms markup. Form related woes are as diverse as the different form layouts we see these days.
I’ve been playing around with a rather complicated set of forms on a client project, and to make matters worse, there are several different form layouts too (not surprisingly, that stylesheet is a real beast). I can’t show you those forms, but what I can show is the proposed forms markup for the Sahana Project: check out this sample page with dummy content.. This is still very much a work in progress, and hasn’t yet been integrated to the Sahana system, but it does indicate the things that are to come.
Matters were complicated because Sahana is built to be scalable (like all major FOSS projects), so it was essential to develop a simple structure for all forms to allow automating the form generation for different modules written by different authors. Basically, I started off with the accessible forms markup of Derek Featherstone , and made the following changes (please do have a look at Derek’s excellent suggestions as I won’t be repeating them here):
- Removed the width specifications from container divs
- Removed all width specifications for input elements from the CSS
- Added the size html attribute for all relevant input elements
- Used unordered lists for radio buttons and check boxes
- Removed absolute positioning of the asterisk used to mark required elements
- Removed the border specifications from input elements
Reasons for changes
Width specifications (CSS) were removed from the container divs to support the liquid layout of Sahana. This is very important for a system that needs to work on all kinds of screen resolutions, including the long forgotten 640×480 and even lower. Sahana is supposed to work on Simputers, and in the future, $100 laptops.
Width specifications (CSS) for input elements were removed after a discussion with the Sahana developers, who argued that it’s a logical/programmatical decision rather than a presentational one (Thanks Chamindra) That was a real eye opener. Consider how we use maxlength to control input size – doesn’t it make sense to delegate the job of sizing the input element to the html (and the browser) too? This led to the decision to add “size” attributes for all text input elements. If you can’t be bothered to view the html of that sample page, this is what I mean:
<label for="lname">Last Name </label> <input id="lname" type="text" name="lname" value="" size="50" />
I haven’t seen this at work anywhere so still not sure if it’s the best option, but we’re considering using unordered lists for radio buttons and check boxes. It not only seems more semantically correct (list of options), but also makes the job of laying them out that much easier.
Update: This is no longer the case – see the end of the article for an explanation.
<ul> <li><input name="radios" id="radio1" value="1" type="radio" /> <label for="radio1">Option 1</label></li> <li><input name="radios" id="radio2" value="2" type="radio" /> <label for="radio2">Option 2</label></li> <li><input name="radios" id="radio3" value="3" type="radio" /> <label for="radio3">Option 3</label></li> </ul>
Derek’s suggestion is great, but sadly we also had to remove the absolute positioning of the asterisk that identifies a required field as the width of the input element was no longer predictable (remember, we don’t use CSS to set width). However, for applications with limited number of forms, it’s still a possibility.
Finally, we removed those fancy borders off our input elements to make them look like real input fields and buttons. I guess it’s a matter of preference, but I like to stick to the browser defaults when it comes to how form elements are displayed. Besides, styling them doesn’t always guarantee good results.
Help Wanted!
Since we’re still at a very early stage of developing the forms markup standard, it would be great to have the input of standardistas to make it better. Please do let us know your thoughts on the above, especially regarding the removal of CSS-specified widths of input elements and using the size attribute, and using unordered lists for radio buttons and check boxes.
Update: Please note that the sample page no longer uses unordered lists (<ul>) for radio buttons and checkboxes, largely thanks to the feedback I’ve got here. As Matt (comment no. 7) and others argued, there’s no need to go overboard with semantics 
This is a live page under work for a real project so such changes could be expected over time. Thanks.
There are plenty of excellent CSS-based forms solutions available online, which provide additional features such as toggable optional fields and help sections. What I have provided here is a flexible, semantically correct, and dare I say, accessible template to which such features could be readily applied.
Like the earlier version, the markup of this template is based on the accessible forms markup of Derek Featherstone. As usual, all input field widths are specified using the size attribute instead of CSS. I’ve explained the reasons in this BSS article.
The markup is quite self explanatory, so instead of detailing stuff here, I’ll let you check out the updated form template.
