I've been designing websites for quite some time now. I think my first page was designed for IE3 with lots of gifs blinking around. When IE4/NS4 were battling on taking over the net, everyone had to write dynamic pages using JavaScript if divs/layers had to be used. Basically like this:

document.write(isNS ? '<layer>' : '<div>');
document.write('content');
document.write(isNS ? '</layer>' : '</div>');

And that was ugly. There were still many popular non-JS browsers around, which drove me (and many others) to the decision not to use divs but tables to layout a page. This ghost haunted me until a few months ago when I had to think about implementing a more complex UI using XHTML.

I read several articles and flamewars about CSS being the only way to go now. Tables are dead, they said. Which sounded good to me, writing semantically correct code, beautiful.

And it does work - for simple forms. Floating and clearing left and right, relative positioning et al. However, when it comes to more complex forms - and complex applications simply do have more than one label/input pair in a "row", that's not bad UI design - CSS still lacks features, especially when it comes to sizing and positioning.

The only way to use CSS-only for positioning of elements on complex forms is to use absolute positioning. Which I am not that comfortable with, although most standard GUI frameworks do it that way.

But many GUI frameworks also have something called "tablelayout". Java has it, Glade has it and .NET 2.0 has it too. Seems like they don't have any semantical problems using tables to position form elements.

Markus says: "When the only way to replace tables with CSS blocks is to emulate a table, better use tables instead."