Left Justified
FeedsResponsible Design - Form Styling
∞ | August 31, 2004 | Category: Design
There have been many great articles about styling forms with CSS, so there’s no point in me discussing that any further. There is one aspect of form styling that sometimes gets lost in the rush — the ‘why’.
Don’t do it for the Design
The following post may fall into the bleedin’ obvious category for many of you, but I think it needs to be reiterated. One mistake I often see is forms that are altered to meet the designer’s tastes rather than styled in an attempt to simplify the experience for the user. Tiny little search fields might look cool but they are a nightmare interact with.
Do it for the People
Forms are something that I use daily, so when it came to making my own I gave some serious thought as to exactly what I would want when filling it out. I believe balancing the point where the design hat comes off and the usability/accessibility hat goes on is what makes a web designer; as such I consider ease of use and reliable functionality paramount when dealing with forms.
Real World Examples
An example of finding the balance came up today on the webstandardsgroup list. Someone was seeking help with a bug in Mozilla / Firefox whereby the dropdown arrow for a floated <select> was disappearing depending on the width set in the CSS. As the designer, it’s your responsibility to make sure the changes you have made to default widgets don’t cause such bugs to be triggered; if they do then the design is what must be sacrificed — not the usability.
Using the :focus pseudo-class to indicate the currently active field is a good practice, but watch out that you’re not doing more harm than good. In my opinion, if background colour changes are going to be made to the active field then the active colour should be lighter than that of the normal state. The user is reading the text in that field, so why make it harder for them? One great looking site I came across yesterday suffers from this common mistake (Ed: not anymore…). If you take a look at the comment form or the contact form in a modern browser you’ll see you would have seen what I mean. Setting the background of the current field to a darker colour decreases the text contrast and also decreases a site’s People Friendly Factor.
So what’s your opinion? As always, comments are open and I’d like to hear some different takes on the matter.
Have Your Say
Sorry, comments are closed on this post.
Well said. This is something I haven’t really thought about, but I guess you’re right. I do exactly what you do: just change the border-color to make the form element stand out more.
It’s something I considered, definitely, but so far nobody with poor vision has given me reason to change it.
Are you speaking from personal experience - with difficulty using my forms yourself, or just estimating the effects?
I’ve tested in Firefox, Safari, IE6 etc and the background gradient really isn’t that much darker on select so I assumed it wouldn’t pose a problem.
Of course I am interested in any feedback and I don’t mind you referencing my site in your example.
I normally style forms with the basic , and I normally stay away from anything more complicated.
I think the majority of websites forget all about the styling of forms, whether they just don’t think it’s neeeded or they do simply just forget. However they’re quite an important part on many sites.
I don’t think there’s a need to be excessive with the stling as long as the forms “fit in” with it’s design then that’s all thats needed.
A border, possibly a background image – but keeping it light in color – and the :focus pseudo-class which is an added neat effect and serves pretty well for usability, is all that’s needed.
Jim: I’m speaking from experience regarding difficulty with your comment form. I’m glad you didn’t take it the wrong way, I had to choose a well designed site or I would have been considered attacking “low hanging fruit”
Chris: Glad you feel that way, perhaps you can finish that part of your new design
I think youve done a crazy job styling your forms … well done mate
Big ups !!!
over and out…
heh, i saw the title and was expected an article about sans table vs table form styling - how about some opinions on that.
I have to say i’m not a big fan of that graphik junkie site, I’m at 1024x768 and with a maxmimised mozilla window the header and title take up pretty much my entire screen, i can only see the date of the first post without scrolling =/
Glen: Each to their own; I happen to really like the header on Jim’s site, but running at 1280x1024 probably helps that.
Regarding tables versus no tables for form layout - I don’t use tables for layout, period. For that reason, I feel no need to discuss the use of tables in this context.
The argument of “forms are tabular data” doesn’t stick with me at all. If forms are tabular data, what are the column headers? Input label and field?? If so, tell me how that is any more semantic than
<label for="pwd">Password</label><input id="pwd" type="password" />
The W3C provide a defined method for linking an input/textarea/etc with its label. That kills the “forms are tabular data” line; as for tables for layout…
Glen, yes. At 1024 it probably is a bit much, but considering my profession and the main scope of my content I estimate that most of my visitors are using much larger resolutions.
As larger screens come down in price this will matter even less in the future.
Good point though. For most client projects I wouldn’t use such a big header image.
Andrew: I reversed the polarity. Better?
true that the label input pair method does have more semantic meaning than the tables method, but what about doing both?
With using a table you can do things like hover styles on the tr so it’s simpler to see which label goes to the input, and you dont have to specifically define widths for every form.
Personally the last 20 or so forms I’ve done have been sans-tables but i’m about to embark on coding a new CMS and i’m wondering whether to switch back just becasue it’s easier and arguably as valid.
PS. thx to whoever it was visited my site from this page, pity it’s so empty atm.
Jim: The good ol’ target audience factor
Forms look much better (but now you’ve nullified my example!)
Glen: Hover on <tr>? So what…
<label>
<input />
</label>
———-
label {display:block;}
label:hover {...}
Same deal.
“…i’m wondering whether to switch back just becasue it’s easier and arguably as valid.”
Arguably as valid? Please, let anyone who thinks they can back up that argument step forward. If you want easy styling and a decent “default display", maybe you should use definition lists for your forms. While I still don’t agree with that method over just label/input pairs, a <dl> would be less semantically offensive than a table.
I’d just like to make it clear that i’m not abandoning label input pairs in favour of tables to DLs, i’m just looking for a way to code my label input pairs so that i dont need to apply per-page form styles to the widths just to make them look right, tables achieve this and you still keep the functionality by using for and id attributes.
the only way to get form fields to line up without specifying width is to use tables, in an ideal world i’d do something like:
<label for="username">Username <input type="text” size="20″
name="username” id="username” /></label>
/* CSS */
label {display: table-row;}
input {display: table-cell;}
Pity only Moz and I hear Saf will support this. The sooner we get display: table* working the sooner we can convince anyone to ditch tables.
but now you’ve nullified my example!
consider it a message well understood. I’m sure you can find some other unsuspecting form to pick on
Andrew: I just discovered your blog and like a lot of what I’ve see so far, including your honest opinion on why you do/don’t use certain practices.
One thing I bring to your attention however is the following:
The problem I see is that you are using CSS to override the inline nature of the <label> element in your comment form to get the design you desire, which in itself is not a bad thing. However, if YOUR CSS is not applied to the document, the form fields smash together in a jumble that is definitely not as easy to read/use.
Considering how well the rest of your site functions without your CSS applied, I think you could heed a bit of your own mantra here to add a little semantic XHTML spacing to these elements to make things as truely easy to use as possible for all viewers without necessarily altering your design decisions.
I must say again though, for the most part I thoroughly enjoy what I’ve seen and read thus far.
You got me Phil! Well spotted
For the record, when this article was written the form elements were split by
<br />s; when I recently re-coded my templates I have obviously forgotten something rather important… Thanks for the heads up.Nit-picky I know, but in reading sites like yours I try and learn new methods of combining usability with the power of CSS presentation by looking at what the author actually uses, so I often study “under the hood” so to speak.
I also noticed you use the <label> tag in an unusual way. I’ve never seen it used to surround the input element it is related to rather than placed before (for text, textarea and select inputs) or after (for checkbox or radio inputs). Any idea how this reacts in alternative devices where the label field is actually needed?
Unfortunately I haven’t been able to test it with JAWS/HPR etc…
The label still starts before the input and is still assocciated with the input via the
forattribute, so *hopefully* it functions the same. Funny you should bring that up though – if it was for a client that sort of thing would never go untested; yet when building one’s own site it is easy to let that sort of thing slip by.** Nit picking is a Good Thing™
What other issues are there similar to the Firefox select issue? Let us benefit further from your in-depth experience.
There have been no other side affects that I am aware of.