is a blog about design, technology and culture written by Khoi Vinh, and has been more or less continuously published since December 2000 in New York City. Khoi is currently Principal Designer at Adobe. Previously, Khoi was co-founder and CEO of Mixel (acquired in 2013), Design Director of The New York Times Online, and co-founder of the design studio Behavior, LLC. He is the author of “How They Got There: Interviews with Digital Designers About Their Careers”and “Ordering Disorder: Grid Principles for Web Design,” and was named one of Fast Company’s “fifty most influential designers in America.” Khoi lives in Crown Heights, Brooklyn with his wife and three children.
All of the blood, sweat and tears that I put into designing that form in XHTML and CSS last week is coming to some good. After much continued fussing, I finally got it to render reliably and consistently across several major Web browsers, so at the very least, my labor satisfied the challenge at hand. But, having heard with near unanimity the general frustration that people feel about forms, I thought I’d do the civic thing and release a genericized version of my work — and let others freely borrow, steal and/or adapt it for their own needs.
Get Yer Red Hot Forms, Right Here
Cutting to the chase: you can view and download the results here. It’s a fairly straightforward piece of work with most (but not all) of the common form elements complying with my layout intentions with a reasonable degree of faithfulness. I tested it in every browser at my disposal and it looks passable in all of them — some better than others, of course. Unsurprisingly, the design suffers a bit at the hands of Internet Explorer, but that browser’s rendition of it is still acceptable, at least to me — I couldn’t justify investing more time into getting it to right.
Right: Yours to do with however you please. Just use your powers for good, not evil.
Use at Your Own Risk
Just be forewarned: I make no claims that this is a definitive example of a form, by any means. I did my level best at simplifying both the markup and the style rules, but by necessity my work reflects the particular requirements that I was faced with. So it’s reasonable to expect that this particular solution will not prove useful to every project to which it’s applied — I can’t guarantee that you won’t encounter problems when working with it, is what I’m sayin’. In truth, my theory is that every unique form requires its own particular finessing in both XHTML and CSS, so creating a ‘universal’ set for every situation seems unrealistic.
You Can Do Better
That said, I would be more than delighted if someone took what I’ve done here and improved upon it such that it’s more readily adaptable for other people’s needs. Lots of my code can be cleaned up and further simplified, I know, and I’d be happy to incorporate any such changes into a new version. If you undertake a major overhaul of it, you don’t even need to credit me — just tell me where I can download and use it for myself, because it would save me a lot of heartache the next time I have to design one of these things.
I like the approach, wrapping each form item in a label and nothing more.
Did you purposely leave the “for” attribute out of the first section of labels (first name, last name, etc..)?
One little quibble, this example has one of the main problems that has always bothered me with non-table based forms: too many classes.
There has got to be a more generic means of varying the layout of input elements while at the same time not being bogged down with classitis (or maybe it’s OK when dealing with forms?).
Good work Khoi. Quickly comparing (having just both Win IE6 & FF here) the only small thing appearing to my eyes that changes is the alignment of the checkboxes & radio buttons that render not exactly aligned in IE.
Alex
justin – there’s no need for ‘for’ when the label wraps the element concerned.
Justin P.: yeah, there are a lot of unique classes and id’s in there. I’d also like to see many fewer, but when it comes down to it, I don’t think forms are conducive to that. The explicit label method (leaving the input outside of the label tags) pretty much demands that the inputs’ for= attributes have unique id’s, so right there it’s not a very pretty way of writing markup. And in answer to your first question, implicit labeling (wrapping inputs inside the labels) obviates the need for the for= attribute, which is why I left them out.
Nice. I’ve been doing very similar things with my forms recently.
How do you intend to handle redisplaying the form when the user doesn’t enter in valid information or misses out required fields?
Would you list the errors above the form or have an initial ‘oops!’ message and then try to squeeze in more specific error messages next to the respective field(s). I personally prefer the latter of these two options as it means the error is highlighted right next to where it occurred. I think this is especially helpful on long forms where otherwise the error message might not be shown on the same ‘screen’ as the field that generated it. It’s easy when you have one field per row but gets harder when you tighten the layout up as you have done. Tight looks nicer though!
Would be interesting to see this form again with some dummy error messages displayed with it.
> implicit labeling … obviates the need for the for= attribute
Not in IE, at least not for me (IE6). That’s why I mentioned it in the first place, I saw the labels yet when I clicked on the text my focus wasn’t were it should have been.
It chooses to ignore Opera’s problem with ‘legend’ in favor of accessibility: (position: relative styled) legends inside field-sets. Explorer has the same problem but is easily styled right with future proof css selector for the good kids (which includes Opera).
In the end it’s about priorities and for most projects I feel accessibility and standards are more important than a styling issue in a browser with a relative small market share (By the way, no idea how this renders on a mobile device where Opera is a pretty big player)
(also removed br’s from form)
hostyle
Ick. Loads of useless markup and CSS rules cruft. I don’t have a Mac at hand, so I can’t test in any Apple browsers right now, but heres a quick (ie. 15 minutes work) stripped down version
Its far from perfect but it looks very similar to your own attempt in the browsers I have tested on: in Windows – Firefox, IE 5.0, 5.5 and 6.0, Opera 7.x; in Linux – Epiphany, Firefox and Konqueror. I’ll work on it a bit more later when I get home.
Nice effort, but it just proves that CSS needs a form of identifying a grid to attach things to. I’m totally for XHTML+CSS over tables, but there are things like forms that just don’t work without tables. Yet.
CSS has a way to grid things: The CSS table model.
It is just dead technology currently, as (you might have guest it) IE does not know it.
hostyle
OmniWeb bug squashed. Just a really unattractive IE 6 bug left which I have a fix for (but I don’t have that browser here to make sure the fix actually fixes). Same URL as above.
Yes, it works, and it works very well. The problem is that CSS does not have a way of defining a grid, whereas tables (for whatever their other failings) *did*.
I’ve got a long ranty screed that I need to write down somewhere about this. It’s a real failing of CSS IMHO.
This is what I love about the standards / blogging /web community. This is going to save someone loads of time, bugs will arrise and get fixed and it’s all for love! This attitude breeds innovation, Nice work and great idea posting it!!!.
Martin said it, but you seemingly missed it. CSS does have a way grid system: the css table model. It’s been in the spec for quite some time and works every bit as well as HTML tables, if not better. The problem is that IE doesn’t currently support it, so it’s sort of useless at this point.
But you should save your “long ranty screed,” or at least re-directed it towards IE, instead of CSS. There is no failing of CSS as you say — there is only a failing of one browser’s support for it.
All this talk about X layout bug in Y browser and such and such. Come on people, if you’re going to make new versions of Khoi’s form, make the freakin’ labels work in IE.
To me, that is the only thing this form is lacking. With that, I think it could be deemed bulletproof. Whether or not to use headings in place of legends and tables instead of CSS should be secondary.
hostyle
Justin.
Simply put, IEs implementation of LABELs is broken. text should work, but doesn’t. Its easily worked around, but annoying that I have to add extra attributes to both LABEL and INPUT for it to work in IE.
hotstyle,
Yes, IE has a broken implementation. This is a known issue and has been for a loooong time. We write CSS hacks for IE all the time, why is this any different?
The reason I’m griping here is because people are saying things like “oh there’s this little layout bug in Opera” or “one small thing left to fix in IE” and such and such. Well there’s that thing with the labels not working in all versions of Internet Explorer, and oh yeah, it’s a really easy fix.
hostyle
Justin. I know. I just haven’t had the time to get back to fixing it up just yet. If anyone wants to have a go by all means do so. I should get back to it this weekend and will post here announcing such when it is finished and fully fixed across all browsers. My commentary on that page was just taking note of my own progress and changes, and notes on what was left to do. While Internet Explorer may be the dominant browser out there, it is not my primary browser, but I will take the time to fix all issues that I find or get pointed out.
It looks fine in the three browsers I used: Opera 8.5, FF 1.07 and IE 6.0 (all of them in Win XP SP2).
I think the alignment issue with the radio and check buttons in IE is a very little issue, we all know IE has its problems but even with the little misalignment the form looks good.
The label clicking and getting to the field issue doesn’t work for input text and textarea in IE, right, but it does work for the radio and check buttons, anyway, I guess most users click in the text box, list box or radio/check button and not in its label, please correct me if I’m wrong.
I deleted the br below the zip field, I didn’t really understand why it was there in the first place, any bug in some other browser?
I also would like to confirm why you are using h3 instead of legend, my tests with the 3 browsers I use revealed some alignment problems, after all the legend should go as part of the fieldset border and there is some left margin which varies from browser to browser and your layout required left aligning everything, am I missing something?
Finally, there is some classitis in here, right, but I think is more semantically correct than using a tables approach.
All of the blood, sweat and tears that I put into designing that form in XHTML and CSS 
I like the approach, wrapping each form item in a label and nothing more.
Did you purposely leave the “for” attribute out of the first section of labels (first name, last name, etc..)?
One little quibble, this example has one of the main problems that has always bothered me with non-table based forms: too many classes.
There has got to be a more generic means of varying the layout of input elements while at the same time not being bogged down with classitis (or maybe it’s OK when dealing with forms?).
Good work Khoi. Quickly comparing (having just both Win IE6 & FF here) the only small thing appearing to my eyes that changes is the alignment of the checkboxes & radio buttons that render not exactly aligned in IE.
justin – there’s no need for ‘for’ when the label wraps the element concerned.
Justin P.: yeah, there are a lot of unique classes and id’s in there. I’d also like to see many fewer, but when it comes down to it, I don’t think forms are conducive to that. The explicit label method (leaving the input outside of the label tags) pretty much demands that the inputs’ for= attributes have unique id’s, so right there it’s not a very pretty way of writing markup. And in answer to your first question, implicit labeling (wrapping inputs inside the labels) obviates the need for the for= attribute, which is why I left them out.
Nice. I’ve been doing very similar things with my forms recently.
How do you intend to handle redisplaying the form when the user doesn’t enter in valid information or misses out required fields?
Would you list the errors above the form or have an initial ‘oops!’ message and then try to squeeze in more specific error messages next to the respective field(s). I personally prefer the latter of these two options as it means the error is highlighted right next to where it occurred. I think this is especially helpful on long forms where otherwise the error message might not be shown on the same ‘screen’ as the field that generated it. It’s easy when you have one field per row but gets harder when you tighten the layout up as you have done. Tight looks nicer though!
Would be interesting to see this form again with some dummy error messages displayed with it.
> implicit labeling … obviates the need for the for= attribute
Not in IE, at least not for me (IE6). That’s why I mentioned it in the first place, I saw the labels yet when I clicked on the text my focus wasn’t were it should have been.
So many questions! Obviously more than a few people are interested in developing their form layout skills further.
Any reason why you chose to go with H3’s instead of LEGEND’s for each fieldset?
Uploaded an alternative to http://webtypes.com/examples/goodform/
(feel free to (not)use it of course)
About this 0.1.alt or 0.2 version:
It chooses to ignore Opera’s problem with ‘legend’ in favor of accessibility: (position: relative styled) legends inside field-sets. Explorer has the same problem but is easily styled right with future proof css selector for the good kids (which includes Opera).
In the end it’s about priorities and for most projects I feel accessibility and standards are more important than a styling issue in a browser with a relative small market share (By the way, no idea how this renders on a mobile device where Opera is a pretty big player)
(also removed br’s from form)
Ick. Loads of useless markup and CSS rules cruft. I don’t have a Mac at hand, so I can’t test in any Apple browsers right now, but heres a quick (ie. 15 minutes work) stripped down version
Its far from perfect but it looks very similar to your own attempt in the browsers I have tested on: in Windows – Firefox, IE 5.0, 5.5 and 6.0, Opera 7.x; in Linux – Epiphany, Firefox and Konqueror. I’ll work on it a bit more later when I get home.
Nice try, but the H3’s look jumbled in OmniWeb, and their alignment is off in Safari.
Nice effort, but it just proves that CSS needs a form of identifying a grid to attach things to. I’m totally for XHTML+CSS over tables, but there are things like forms that just don’t work without tables. Yet.
Aegir: I’m not clear on why you think this effort proves that you still need tables. It works, right?
my alternative from the above post properly linked.
thanks,
Thomas.
CSS has a way to grid things: The CSS table model.
It is just dead technology currently, as (you might have guest it) IE does not know it.
OmniWeb bug squashed. Just a really unattractive IE 6 bug left which I have a fix for (but I don’t have that browser here to make sure the fix actually fixes). Same URL as above.
What do I win? 🙂
Yes, it works, and it works very well. The problem is that CSS does not have a way of defining a grid, whereas tables (for whatever their other failings) *did*.
I’ve got a long ranty screed that I need to write down somewhere about this. It’s a real failing of CSS IMHO.
This is what I love about the standards / blogging /web community. This is going to save someone loads of time, bugs will arrise and get fixed and it’s all for love! This attitude breeds innovation, Nice work and great idea posting it!!!.
Aegir-
Martin said it, but you seemingly missed it. CSS does have a way grid system: the css table model. It’s been in the spec for quite some time and works every bit as well as HTML tables, if not better. The problem is that IE doesn’t currently support it, so it’s sort of useless at this point.
But you should save your “long ranty screed,” or at least re-directed it towards IE, instead of CSS. There is no failing of CSS as you say — there is only a failing of one browser’s support for it.
All this talk about X layout bug in Y browser and such and such. Come on people, if you’re going to make new versions of Khoi’s form, make the freakin’ labels work in IE.
To me, that is the only thing this form is lacking. With that, I think it could be deemed bulletproof. Whether or not to use headings in place of legends and tables instead of CSS should be secondary.
Justin.
Simply put, IEs implementation of LABELs is broken. text should work, but doesn’t. Its easily worked around, but annoying that I have to add extra attributes to both LABEL and INPUT for it to work in IE.
<label>text <input … ></label>
Ack, previous post got mangled. Hope this works.
hotstyle,
Yes, IE has a broken implementation. This is a known issue and has been for a loooong time. We write CSS hacks for IE all the time, why is this any different?
The reason I’m griping here is because people are saying things like “oh there’s this little layout bug in Opera” or “one small thing left to fix in IE” and such and such. Well there’s that thing with the labels not working in all versions of Internet Explorer, and oh yeah, it’s a really easy fix.
Justin. I know. I just haven’t had the time to get back to fixing it up just yet. If anyone wants to have a go by all means do so. I should get back to it this weekend and will post here announcing such when it is finished and fully fixed across all browsers. My commentary on that page was just taking note of my own progress and changes, and notes on what was left to do. While Internet Explorer may be the dominant browser out there, it is not my primary browser, but I will take the time to fix all issues that I find or get pointed out.
Hi, thanks for sharing your work Khoi.
It looks fine in the three browsers I used: Opera 8.5, FF 1.07 and IE 6.0 (all of them in Win XP SP2).
I think the alignment issue with the radio and check buttons in IE is a very little issue, we all know IE has its problems but even with the little misalignment the form looks good.
The label clicking and getting to the field issue doesn’t work for input text and textarea in IE, right, but it does work for the radio and check buttons, anyway, I guess most users click in the text box, list box or radio/check button and not in its label, please correct me if I’m wrong.
I deleted the br below the zip field, I didn’t really understand why it was there in the first place, any bug in some other browser?
I also would like to confirm why you are using h3 instead of legend, my tests with the 3 browsers I use revealed some alignment problems, after all the legend should go as part of the fieldset border and there is some left margin which varies from browser to browser and your layout required left aligning everything, am I missing something?
Finally, there is some classitis in here, right, but I think is more semantically correct than using a tables approach.
Regards!
I’m trying to get my form working. it can be found here:
http://www.karen.hik.se/turbine/turbine/membership.html
the thing is, I can’t get it to send me the info via mail. I know there’s something I’m doing wrong but I just can’t figure it out.
I’d appreciate any help and please contact me through my mail.