Question about template structures

[lcdweb]

Dave and Lobo,

I'm still working through some mods to the templates to *hopefully* improve usability. 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.

Anyway, I'm hopefully making some of these mods for the greater good, so I wanted to get background on any thought processes you guys had when developing these.

For an example, see:
Event/Form/Participant.tpl

It starts out with a table structure and then shifts abruptly to dl/dt/dd

-Brian

[Dave Greenberg]

Brian - The inconsistencies you've noted 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 with varying degrees of complexity. 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 (<dl><dt>... ) 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 taborder works (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:

* Overflows 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.

I've posted a version of this "conversation" as a blog post - so we can hopefully grab a few more eyeballs :-)

http://civicrm.org/node/326

[lcdweb]

One of my clients is a group that serves persons with disabilities. It's been a while since I had this specific conversation with them, but as I recall, they said that most of the current screen reader technologies do a pretty good job of handling tables, so long as table descriptions and th row header tags are respected. It's not the issue that it once was. I'll run the question by them again and do some digging to seek clarification.