Complex Form Layout - Definitions Lists, Tables, Fieldsets...

Brian Shaughnessy is working on some layout improvements for a client - which may potentially result in some core code contributions. He posted this question on the forums today: I notice there's some inconsistencies regarding how some of the forms are laid out. Specifically, I'm running into forms that use a mix of table/tr/td tags with dl/dt/dd tags to layout the form labels and fields. This makes it more difficult to have consistency laying out the page using css, because those tags are structured differently. My personal preference is to use table tags exclusively. Because of the built-in structure of dl/dt/dd tags, I find them hard to layout on a consistent and growable/shrinkable manner. I know that in a strict-css-world we shouldn't use table tags for layout, but for a long list of form labels and fields, many of which have option contingencies, tables seem like the most logical way to handle layout. Since this is an issue we've struggled with, and because we're looking at changes to some key screens and forms to improve usability - I'm posting my response here as a blog. Hopefully we'll grab a few more eyeballs and get some useful input from folks with expertise in this area... The current inconsistencies in our form templates are a result of a sequence of attempts on our part to figure out the best accessibility and standards-compliant/cross-browser and resolution compatible way to handle forms (especially complex forms with conditional and variable sections). Frankly, it's also due to the fact that we don't have any real CSS / web-design experts on our team. AND, we have the challenge that CiviCRM forms are "contained" in a CMS page with it's own layout variables - page structure, theme, style directives, etc. Doing a Google search on "html for complex input forms" - for example... it looks to me like there's still a fair degree of disagreement over the "right way" to lay out forms. The CSS gurus will insist that tables are not the appropriate tool - and then provide beautiful div or definition list examples - but always for very simple cases (3 fields, label + input). Accessibility guidelines seem to discourage tables, but some folks say they're fine as long as you use attributes properly, use <th> for field label cells and tab-order works properly (I may be missing a few caveats here...). Comparable edit forms in some of the other CRMs (Sugar, Computility...) definitely use tables. Bottom line is we decided to use definition lists a while back for simple forms, and tables for more complex forms. Subsequently, we converted forms or sections of forms "back" to tables when we had layout issues we couldn't figure out how to fix using definition lists. Given the hacks we wind up making for definition lists, and the fact that the content of our forms and labels is user-configured in many places (which means we don't know how long labels will be, what custom fields might be injected, etc.) - my tendency is to move towards tables for all forms going forwards. However, even with tables we have issues:

• overflow not being handled properly (so form buttons or fields get truncated with lower resolutions and smaller screen sizes)
• Too much scrolling / inefficient use of screen real-estate
• etc.

It would be awesome to get input on this topic from folks with expertise in these areas (accessiblity, css, usability....) as we take another pass at improving our forms interfaces! Specific examples of usable, standards-compliant, accessible COMPLEX FORMS would be very useful. A patch which implements "best practices" form coding for our contact Edit form and/or other CiviCRM forms would be really great.

Comments

I don't know if it helps at all, but this is an interesting little gizmo to give some ideas... having something like this in CiviCRM for the form challenged would be fantastic... Some of the forms can become quite complex, and they aren't using tables, but I think they look neat. http://wufoo.com

Just thought I would mention it...