Forms Markup and CSS
2006.01.12
Update: The forms markup and CSS mentioned in this article has been updated. Check out the new template here.
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.
17 Comments
Comments Feed
Maaike
January 12th, 2006 at 6:41 pm
Well… I’m not quite a standardista, but I do have an opinion.
I think using unordered lists for radio buttons and checkboxes is a good and sensible decision. After all, they really are lists of options.
However, I disagree about setting the width of input elements in the html. I don’t see how the sizing of boxes, fonts etc is semantically any different from sizing form elements. The maxlength is indeed a programmatical decision (after all, you can’t actually *see* it), but sizing is about looks, not content.
Mats Lindblad
January 12th, 2006 at 6:47 pm
I agree that the size of a input field isn’t a presentational one. Although it’s alway good to have a fallback plan.
I was reading Roger Johanssons recent post on CSS 3 selectors explained and didn’t get the point of using
:not()so I checked the spec to see if they had a better explanation. Their example gave the idea for this snippet:input[type="text"]:not([size]) {width: 15em}This works in Firefox and gives any text input field which is missing the size attribute a width of 15em, like I said, this is just a fallback in case you missed one field.
I think the Sahana form looked good and thanks for the link to Simply Accessible.
Hope I’ve been helpful. :)
Rob Wilmshurst
January 12th, 2006 at 7:05 pm
I pretty much agree with Maaike. However, I usually use defenition lists rather than a simple unordered list because they give more control over the <label> element (and are ever-so slightly more samtically correct)
<dl>
<dt><label for="field1">field 1 Label</dt>
<dd><input type="whatever" id="field1" /></dd>
</dl>
I’d define width in the CSS using EMs - it gives a very similar width to using the “size” attribute.
I see Maxlength as programatical, so leave it in the markup. But the size attribute is a presentational thing, showing the visible width of the input. In my book at least that makes it the responsibility of the CSS.
My two pennies :)
Prabhath
January 12th, 2006 at 7:19 pm
The “size” attribute is a tricky issue, and I think the decision depends a lot on the context. For web based applications, the size of the input fields could be seen as a programmatical decision because it provides an important cue as to the type of input expected. Unlike the font declarations and colours, it seems more closely linked to the application logic. Anyways, we haven’t really finalized anything so your input is much appreciated.
trovster
January 12th, 2006 at 7:36 pm
Rob: That’s exactly how I setup my forms. Adds a stronger association between the elements, and continuity when styling.
I like the idea of the unordered list for radio/checkboxes.
ismael
January 12th, 2006 at 8:21 pm
Hi.
Over the time I’ve come to use the following structure for my forms:
My form
my field
my field 2
This gives me enough control over the layout (’s generally are rows) and fexibility.
Matt Wilcox
January 13th, 2006 at 2:06 am
There’s sometimes a danger of going overboard with semantics. I can, for example, define almost anything as being a list. A webpage might be seen as a list of ordered paragraphs, and even a paragraph is just an ordered list of words, and if I were to mark them up as such, well, it’s valid and correct. Just a bit obtuse. The question that I try to remember to ask myself when I’m getting carried away is this: If I were to use this markup I am adding additional meaning (e.g. ‘this paragraph consists of an ordered list of words’) - but to what end? What does it gain anyone in their understanding of the content? (Isn’t it already implied that a paragraph is an ordered list of words? Does it need spelling out semantically?)
In a similar way I often find the normal form elements offer sufficient semantics and layout potential to not need additional semantic support in the markup. Take the radio options as an example: yes, they are a list of options, and would belong in a ul, or an ol, maybe even a dl. But a radioset is by it’s very nature a list of choices, the meaning is already inherent in and of itself. Wrap each input in it’s own label, wrap the lot in a fieldset with a legend and you’re done. Less HTML to contend with, still very semantic - but less verbose about it. Of course, some occassions demand the extra clarity, or increased styling potential, of different mark-up…
Using ul’s for forms isn’t wrong, but it’s not neccesarily any better than not using a ul. Whether or not that is the case will depend on their context within the form and the page.
ismael
January 13th, 2006 at 5:02 am
Sorry i didn’t use html entities, my example was lost.
Prabhath
January 13th, 2006 at 8:49 am
ismael: Could you point us to a sample page?
Matt: More than anything else the main reason for using a list for radio controls was the ease of automating the form generation. The programmers will not be marking up their own forms but will be using a general script to create them for their modules within the system. In such instances where we don’t have direct control over how the form will be marked up, and we need to create a script that handles any kind of form without a hitch, lists give a nice way to distinguish radio buttons and checkboxes from other form controls. And the nice part is, even if it’s not the best way, it’s still semantically not incorrect (ooo, double negative ;-) ).
Bramus!
January 13th, 2006 at 1:35 pm
Most of the time, I use this:
form
___fieldset
______legend - /legend
______
______label
______input
______
______label
______input
______
___/fieldset
___
___fieldset
______
…
___/fieldset
/form
That’s how a form should be … not need of adding any type of list. A form is a form, not a list.
–> In a form, things are grouped with a fieldset.
–> In a form, fields are described with a label.
Those 2 together : that’s more than enough and provides plenty of options.
Prabhath
January 13th, 2006 at 7:34 pm
Bramus: Sahana forms are marked up like that. Lists are used for radio buttons and checkboxes only.
Kim Siever
January 13th, 2006 at 11:05 pm
I stay away from using lists form form controls. An unstyled page looks unweidly with a bunch of radio buttons each preceded by a bullet.
Bramus!
January 14th, 2006 at 7:28 am
Prabhath I should have expressed the “A form is a form, not a list.” a bit more … see Matt Wilcox’ reply I have the same opinion as him: there’s no need to add extra markup for an option list. Besides, radiobuttons already are grouped by their name attribute.
The structural code I posted is one that I use, and I think it offers more than enough option to play with.
The thing you actually are proposing seems more like an extension to the current form standards … you kinda imply to add sth like an optgroup for option elements, but then for radiobuttons and checkboxes. But unfortunately this does not look to happen since I don’t see it anywhere in the Web forms 2.0 Working Draft … maybe it’s an idea to notify the creators of the draft of?
Best regards,
Bram
Bramus!
January 14th, 2006 at 7:37 am
Some more W3-site-digging … most likely the group element will become available in the XForms module of XHTML 2.0, but that’s still a long way to go… Above that they haven’t described it yet (only thing up there is “group elements can freely nest.”), so there’s only to guess what it will be(come).
Prabhath
January 14th, 2006 at 10:50 am
Thanks Bramus. I guess using lists is a questionable idea afterall.
Then we’ll have to resort to the <br /> to stop radios and checkboxes appearing inline. Giving them a display: block and/or floating is an option, but then you need to give them a separate class due to poor browser support for attribute selectors (i.e. IE).
ismael
January 26th, 2006 at 8:57 pm
What I meant was:
fieldset
–legend
–p
—-label
—-input
–p
—-label
—-textarea
etc
Ben Boyle
April 24th, 2006 at 6:32 am
That’s a nice form design Prabhath :)
I like the error summary presented at the top, and I’d like it even more if each message linked to the relevant field. I can’t take credit for that suggestion though, I read about it at Communicating error messages accessibly.
The issues with grouping radio buttons are frustrating. The problem I find is that HTML forces us to treat each choice as a separate control, and there is no clear element for the entire group. In XForms this is completely different - the xforms:select1 element represents the group and each choice is an item within the group. The entire group is represented by one control, which will be much easier to deal with, very similar to select lists in HTML (and makes sense, they are essentially different presentations of the same functionality).
The best suggestion I have come across for dealing with this in HTML, and someone posted this above, is to use fieldset for grouping radio buttons. I confess I haven’t tried this in practice myself (yet).
Thanks for sharing your insights! :)