Form Doesn’t Function

The black art at the heart of information design in XHTML and CSS is wrestling forms into some semblance of orderliness. In building a small site for my girlfriend (more later), I spent about three times the effort that should be necessary for getting a handful of standard form fields — name, address, phone, email etc, — lined up properly. It was a relatively straightforward job in Safari, surprisingly difficult in Firefox, and just hopeless in Internet Explorer. Fields were misaligned, clearing oddly, refusing to conform to declared widths… painful.

Maybe it’s just me, but even in the days of table-based design, form elements drove me batty. I’ve never come across a reliable primer on how to bend forms to a designer’s own will — if you know of one, I’ll be eternally grateful — and I think it’s because in a medium that’s notorious for its inconsistencies, form elements are the bottom of the barrel.

Right: Internet Explorer hates my form.
Form Elements
  1. You’re right about that one. Legend elements are by far the hardest to achieve consistency with in my experience. The problem is that browsers and operating systems define their own styling of form elements which might not necessarily be able to be described (or altered) in CSS.

    Check out this article.

    Wrapping form inputs in their label elements can help greatly with positioning them side-by-side and this appears to be the majority of your trouble.

  2. I once made a form like that, and finally I figured out that wrapping the label+element in a div of their own and then floating THAT worked reasonably well.

    Good luck.

  3. I usually like the way your comment form is lined up, and use that often myself, but yeah, it’s quite a mess when you want a certain layout and it won’t work. That’s why I always make my form layouts up on the spot, except when I need to do it like on my own site or here.

    Also: labels containing the inputs solve many problems and ease the process in many cases, but it’s not always the right thing to do. Like, when you need a layout like this comment form’s. Hm. What a mess!

  4. Funny you should write this now – I’ve been thinking the same thing recently and started playing with form layouts myself. I’ve come to the conclusion that they’re a pain in the arse, especially in Internet Explorer (Windows).

    Here’s the first of my experiments: FormsExperiment.html

  5. Thanks for the tips everyone. Actually, I had my inputs wrapped in label elements all along, but things still look wonky in IE. I’m sure I’ll figure it all out though, given like another 40 hours or something.

    Olly: nice work on your form experiment there. No rounded corners show up in Safari, but otherwise it looks sharp. I’d be curious to see how easily you’re able to set some fields next to one another with floats. That’s what’s killing me. Damn you, floating form fields!

  6. I have been using

    * {
    margin: 0;

    I then set everything myself, means I dont get a lot of head aches across browsers and know for a fact everything starts equal. (well as much as one can know with IE) Works just as well with troublesome forms. eg

    #formid * {
    margin: 0;

  7. This “multiple fields on one row” game is harder than it seems! Damn you, Internet Explorer!

    The resetting margins trick seems to help, but the lack of support for things like input[type=”text”] means I’ll have to suffer from classitis now. Bah humbug! 🙁

  8. I wrap each input/select/textarea-label pair in a div, with every checkbox/radio-label pair in an li within a fieldset. Having a containing element really helps… Every browser seems to treat elements’ margins and padding slightly differently and being able to offload some of those onto a container helps keep me sane…!

    Failing that, I don’t have any problem with a neat, clean table for forms, as long as they’re sensibly marked up.

  9. I too empathize with your plight. I totally have up on the idea of using legend tags… too inconsistent. Instead I now use a h3.legend. Can also confirm the extra markup of wrapping each line in a (form row) can also make things a bit easier, but then it’s not purely semantic at all any more, is it… 😉

  10. Have a look at FormsExperimentTwo.html. not quite as tidy as the last one but what the hell.

    It seems that you start to get vertical alignment issues when mixing more than one type of form element on one row (e.g. text boxes and buttons). The CSS vertical-align property lets you work around it to an extent (for instance you can make the top of all of them line up).

    Resetting the margins and padding back to 0 helps quite a lot too.

  11. Yeah, no kidding. I’ve just had to bite the bullet and layout forms in tables. In web apps especially, you just have so many to deal with that dinking around with CSS specially for each one just takes too long.

  12. I’m with Andrew – bite the bullet and use simple tables – it’s not worth the time right now. Olly’s samples are great though and I will definately be taking a closer look at them. Thanks for the info.

  13. I’ve been wrestling with complex forms for a while now, and I found myself going back and forth between tables and not.

    When you have a input element in a “row”, taking a standards approach is rather easy. It’s when you want to start lining things up in a more column manner (but more flexible than tables) that it quickly becomes a nightmare.

    Khoi, your example shows perfectly how well tables are NOT suited for forms and it also shows how tricky it can be using a “standards” approach.

    Using tables for something like that is just crazy, sometimes a row will be 4 columns, sometimes 1, sometimes 2. That’s not a table. The typical div+label+input approach does not really work in those cases, we need something more powerful!

  14. I rather like this comment form actually 🙂

    I have never had a problem using fieldsets or legends, so would one of you care to explain what your problem with them is? I think that going through the trouble of tables is more hassle than working with CSS. At least you can change CSS quickly. I’d say work with floats, and maybe a span or two to control the size? I’m not too sure, I usually stick with vertical columns, and I haven’t worked on any of my web aps in a while. Good luck Khoi!

  15. Okay, so I’m grateful for everyone’s tips, and both gratified and dismayed that no one has yet discovered some heretofore secret, exceedingly easy method of making forms work with CSS. I’m not at the point of wanting to use a table yet — I really want to conquer this! If I can get it to work out smoothly, I’ll post a genericized version of the code for everyone to download. Thanks, all.

  16. I feel your pain, Khoi. We’re working on a total redesign of FeedBurner, and initially attempted to abandon tables for all the forms. After a week of struggling, we decided this wasn’t practical given 1) the number of forms in the application and 2) the variations that can arise between forms.

    There are a number of good insights in this SimpleQuiz conclusion by Dan Cederholm. When it comes down to it, the benefits of not using tables for forms are very few. Wanting to “conquer this” is a common feeling — but it’s important to look at the big picture and see what advantages you’ll gain by not using tables.

    Having said that, I tend to structure forms like this when not using tables:

      li label /label input /li

    And in the css…

    label {
      float: left;
      width: 200px;
      text-align: right;

    li {
      width: 100%;
      float: left;

    My apologies if the details of that code example are slightly incorrect. Anyway, let me know what you come up with.

  17. I think it was already mentioned, but form fields use a box model, but not necessarily the same one as divs etc for each browser.

    I start by setting all margins and padding to zero and then go from their and work out who is using what stupid box model and try to use one the box hacks to fix it.

    Why doesn’t everyone use IEs quirks box model!!! It’s the only one that makes logical sense.

Thank you! Your remarks have been sent to Khoi.