Dizzy heights

My latest project has taught me the downside of setting a height to an element. I wanted to add a background image to an h2 tag - just a small image to give the header a lift. It needed to be positioned just above and to the left of the text so in order to acheive the desired effect, I set some padding to the left so that the text would sit free of the image, and a height to the tag plus some padding to shift the text down a fraction. I got the desired effect which worked across browsers and thought no more of it. Until, I wanted to take a check of the page with the font size increased. Yikes - suddenly the header text overlapped the text below it in an ugly and illegible fashion. I had an inkling it was the height that was causing the problem and so removed that attribute from the stylesheet. Problem resolved. I then tweaked the padding fractionally and still got the appearance I was after. Adding height to the element was completely unecessary as padding alone enabled me to manipulate the text around the background image. When the font was enlarged, there was no ugly overlapping issue and the page behaved as expected. SO - I will think twice before needlessly adding a height to an element.

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!