CSS and Forms Continued
Last week I made one of my typical blanket statements, stating that CSS is useless for layout of a complex form and suggesting the use of tables instead.
In the comments somebody called Mike Golding (Remember him? Used to run a site called Notestips) made it clear I was very wrong. Mike has written about this and proven it by example.
I've not tried using this approach for anything other than simple forms, like those used for commenting on this site but I will try it next time I need to. Something tells me I'll stick with tables though. In Mike's example there are oddities and differences in the way the form displays in IE and Firefox. That's the thing with CSS layout - you know what you expect, but never really know what you're going to get. With tables you know where you are.
Anyway, I don't pretend to know everything. My blanket statements are just my opinion. Don't believe everything I tell you!
Skip to the 
You can subscribe to an individual
I think it is a little of both. I have used "chunks" of CSS layouts within a larger table. The larger table helps keep some of those oddities (like Mike's example in FF) to a minimum, while giving you the flexibility of CSS in smaller, more managable sections.
<mode value="pedantic">
In a typical form layout, one could reasonably argue that the data are tabular:
label:value
label:value
... meaning, of course, that CSS is all well and good and proper, but if you aren't using a table, you've got it wrong anyway. A lot depends on the complexity of the layout, and whether or not your tables makes sense as tables.
</mode>
whether there are oddities and differences in the way the form displays in IE and Firefox is less important as long as the functionailty is the same. it's the content you want people to be able to reach/use rather than the surrounding design.
i actually find it easier to get the accessibility bit right if you skip the tables completely as in
{Link}
(which i'm sure is far from perfect, but still...)
Ake. You must have open-minded understaing customers for them not to worry about badly aligned form objects. Even a pixel out of place and most will flag it as an issue
Have to agree with Jake.
Take Mac OS into the equation. It's aqua style buttons frequently have their text cut off as lazy designers have used a width attribute for the button, which on the mac needs to be wider to account for the curved edges.
Not good if you don't know what two buttons say and one is to reset and one is to submit!
"Delegate" and "Delete" would be more of a problem :o)
That's the reason why I use CSS for buttons instead of leaving the OS to draw the button for me.
We hate Domino throwing HTML for us? well, I must to add that I hate OS's drawing buttons for me.
.::AleX::.
I'm still of the thinking that css is not yet good enough (or consistant enough - especially across browsers) for complex form data. Which is a shame - but thats where we are at still.
Tables "currently" work better - are easier for people to understand (at a developer level) and are just more natural to use (which I think is an important factor)
You have to remember as well that for most budget concious companies - they do not want you spending days getting a css form correct by doing it the perceived "right way" - when you could have done it so much quicker using a table.
Obviously its about common sense in whats right for each scenario - ahead of CSS snobbery!
I think you should look at the following example:
{Link}
I find it difficult to design Forms using CSS, but that doesn't mean it can't be done.
That still leaves the "can be done" versus "should be done" argument. I happen to think that label<->value is a tabular relationship, and that merely linking the values with <label> for accessibility is not enough to do justice to the data being marked up.
Forgive me Stan, but I think "merely linking the values with <label> for accessibility" does not do justice to the example cited by Lee above.
At least that example has some semantics, whereas the example originally given by Jake http://www.codestore.net/store.nsf/rsrc/bloggifs30/$file/tables.html
did not.
Now I'm not saying whether form data should be considered as tabular data (and therefore presented within a <table>) or not but, to be honest, that is a secondary concern. Associating a label with a field is something we do with the <label>. The reason we're doing it is to give our markup more meaning. One of the benefits we derive from that is better accessibility.
Actually, it DOES do justice to the cited example -- which is a great example of how wrong-headed the "get rid of tables at all costs" attitude can blind people to the fact that they are often electing to throw semantics out of the window in order to prove a point. Missing entirely is the concept of the tabular relationship, which is ESSENTIAL for semantic markup, not a "secondary concern". The label for a checkbox or radio, for instance, decribes the relationship between a widget instance and a particular value when it is properly used, not between the value's meaning and the value itself. Leave out the table, and you leave out the meaning. It's really that simple.
Stan,
I'll ignore the "get rid of tables at all costs" comment as I don't know where that came from. I certainly didn't say that and I haven't seen that in this thread.
My observation was simply that if you mark up your forms with <label>, at least someone could write some code that would be able to associate the labels with their controls. If you don't use <label>, whether you've marked up your form in a table or not, you can't do this. All we're doing here is using the appropriate tags according to their meaning (semantics) as defined in the HTML spec. It may sound obvious, but it's amazing how often it doesn't happen. I know - I've done it!
Now if you can layer some more meaning on top of this by marking your form up in a table, then all power to you - and I'd love to hear more about it.
Oh no! Mike Golding's site is gone! I was just there last week. This is tragic news, there were so many resources that I relied on there!
Oh woe!
Jake, if this is a permanent scenario, any thoughts on listing some of those great resources (from Mike's resource page)?
<label> for checkbox and radio is devorced from the meaning of the FIELD -- it merely labels a particular value. Again, <label> is not sufficient of itself to explain the relationship between the name and the value of a given datum -- if you don't use a table, you are effectively removing at least a part of the meaning. <label> may be correct, but it is not semantically complete. I would think that that would be an easy thing to comprehend, but I'm apparently underestimating people's ability to see the obvious. Tables alone for layout are bad because they use data structures to accomplish visual aims. Failure to use tables when expressing tabular data structures is at least as wrong. Failure to use tables to denote tabular data structures while claiming semantic completeness and citing standards is an order of magnitude worse.
Oh, and Patrick -- Mike's site isn't gone, it's just being updated at a glacial pace since he's found his photographic passion. His last two entries (as of this writing) are dated 20 May and 9 June.
@Stan:
I take your point about <label> not being sufficient for your purposes. This stems from the fact that HTML forms contain controls rather than fields and a label defines the label for a control, rather than a field.
I can see that you could add this meaning via a table structure, but that's not the only way. I've often used <fieldset> and <legend> to add this to a set of checkboxes or radio buttons.
To anyone else interested in the debate about whether form should be done in tables or not, this {Link}
is a pretty good place to start.
Blop, you point us to one single comment backing up your point indeed, but that's not the summary of the article itself. So I suggest that everybody scrolls up and reads the article itself as well, including the summary.
I still don't see one convincing argument, why tables have to be avoided in forms. I'm not talking about the "layout of a form" on purpose, as "layout" IS ambiguous in this context. Placing controls and lables on a screen intended for user input is not about layout in a presentational sence, but in the sence of making the purpose of the form clear and achieving ease of use (for all kinds of clients, if you want to). With this in mind, I can happily cite the only restriction on the use of tables mentioned in HTML 4 specification: "Tables should not be used purely as a means to layout document content as
this may present problems when rendering to non-visual media."
My simple rule of thumb for appropriate use of tables is: If setting the borderwidth to 1 breaks your design, don't use a table.
First of all, a big sorry to everyone. I meant to link to the entire thread rather than the last comment. Although that comment is food for thought in itself.
I really haven't seen any convincing arguments either way. I appreciate that some forms are definitely tabular in nature, e.g. an expense form or timesheet application, where the form mimics the paper version. But the vast majority of forms you come across don't fall into this category.
In future, if the form isn't obviously tabular in nature then it probably doesn't matter whether I use a table or not. Either way, I'll try to use the appropriate markup (<label>, <fieldset>, etc.) so that (a) the page is valid HTML, and (b) the form will work with more than just visual browsers.
@harkpabst:
Thanks for spotting that. I like the test :-)
ah that old yarn.
yep, its tables for me for that sort of thing. to do the css thing for tabular data is just silly, and a lot of work for a more inconsistent result.
Blob, problem is, I don't always stick to my own rule, depending on current level of laziness. ;-)
But I'm working on it.