Forms
Whenever I am asked to construct a form, whether simple of complex, I am always faced with the dilema of how exactly to construct it: whether to build it within a table or to persist with semantic markup and rely on CSS.
I guess the first question should be, does a form present tabular data? The obvious answer, I imagine, is 'no'. If we consider exactly what a form is, we could say its a vehicle for presenting a set of questions to the visitor with a means to answering them. A question might present a visitor with a free text area or input box. The answer to the question might be narrowed by multiple choice via select dropdowns, check or radio boxes. Is it therefore necessary that the question and answer appear on the same row for it to make sense to the visitor? Again, the answer is 'no'. The answer could be placed beneath the question, on a new row. The fact that often the answer is aligned horizontally alongside the question is often to save vertical space and /or to assist with the usability of the form. These reasons are therefore presentational. Unlike tabular data, arranging the information in rows and columns is not essential to the meaning of the data presented.
So I think I'm fairly clear in my mind that forms should not be presented in tables, this aside from the accessibility issues of presenting forms in tables (which is a whole new can of worms to be openend on another day). Yet, I am ashamed to say, I often resort to building them thus, if my presentational aims require. Despicable. As usual its the time factor that so often determinse this. No excuse, I know, but often that's how it pans out. I spend some time struggling to arrange answers to questions so that all the answers in rows align and i so far have failed to derive a solution outside the table that works. I dabbled with inline blocks and floats which I thought would be the answer to my prayers, however support for this across browsers is eratic. So one of my New Year's Resolutions is to find a method of presenting forms that does not rely on a table. I'll let you know how I get on!
I guess the first question should be, does a form present tabular data? The obvious answer, I imagine, is 'no'. If we consider exactly what a form is, we could say its a vehicle for presenting a set of questions to the visitor with a means to answering them. A question might present a visitor with a free text area or input box. The answer to the question might be narrowed by multiple choice via select dropdowns, check or radio boxes. Is it therefore necessary that the question and answer appear on the same row for it to make sense to the visitor? Again, the answer is 'no'. The answer could be placed beneath the question, on a new row. The fact that often the answer is aligned horizontally alongside the question is often to save vertical space and /or to assist with the usability of the form. These reasons are therefore presentational. Unlike tabular data, arranging the information in rows and columns is not essential to the meaning of the data presented.
So I think I'm fairly clear in my mind that forms should not be presented in tables, this aside from the accessibility issues of presenting forms in tables (which is a whole new can of worms to be openend on another day). Yet, I am ashamed to say, I often resort to building them thus, if my presentational aims require. Despicable. As usual its the time factor that so often determinse this. No excuse, I know, but often that's how it pans out. I spend some time struggling to arrange answers to questions so that all the answers in rows align and i so far have failed to derive a solution outside the table that works. I dabbled with inline blocks and floats which I thought would be the answer to my prayers, however support for this across browsers is eratic. So one of my New Year's Resolutions is to find a method of presenting forms that does not rely on a table. I'll let you know how I get on!
posted by spannah at
10:33 AM
0 Comments:
Post a Comment
<< Home