It's been a web design mantra for years now - tables are for data, not for structure.
The simple reason is that it is easier to apply CSS positioning to elements outside of tables - whereas, moving a table cell has compounding knock-on effects - column and row issues which need to be cleaned up before the table will be valid and display properly again.
Another reason is that tables used for structure do not make use of a lot of the other related elements which help browsers to render the table (colgroups, for example), making them pretty slow to display on a page.
One further reason is that a table is semantically linked with the idea of data - and when creating accessible pages, tying structure to data with this semantic link is confusing, and just wrong.
There are plenty more reasons - and I'm not about to go into details on all of them right now. The ones I have brought up are the most relevant to the following discussion and examples.
Despite these myriad reasons, tables are still a major resort for designers having problems with getting their forms aligned properly and consistently.
Some designers have made some efforts to overcome even this, and here are a couple of solutions which use simple CSS to get the results.

This example is similar to quite a few CSS based forms that I've seen. It is pretty low on markup in the form itself, and the CSS is incredibly simple.
CSS:
form div label { float: left; clear: both; width: 125px; } form div input, form div textarea { float: left; width: 125px; margin-bottom: 10px; } form div button { float: left; clear: both; margin-left: 125px; }
HTML:
</p><form> <div> <label for="login_username">Username:</label> <input id="login_username" name="login_username" type="text" /> <label for="login_password">Password:</label> <input id="login_password" name="login_password" type="text" /> <button>Login</button> </div> </form><p>
So, instead of moving the markup for the table cell(s) containing the inputs, if I wanted to move them a little, I could just make a couple of changes to the CSS. While the login form looks okay with this example, I just don't think that it is easily expanded into forms which would have even just a few more inputs and information: There are also issues of semantics. The <label></label> go some way to address this in the simple login form, but the detailed registration form cannot be dealt with in anything like as simple a method.

I came up with this solution about a month ago, and have since been implementing it into new site designs.
To tie up the extra information related to each input, I'm going to recruit the oft-overlooked <dl></dl> element.
The definition list is a handy way to link details with another element. The way it works is that in the list, there are one or more definition terms (<dt></dt>), each having one or more definitions (<dd></dd>) after them. Using the relationships of this set of elements, we can link the comments about the inputs more easily:
CSS:
form dl, form dt, form dd { padding: 2px 0px; margin: 0px; } form dt { float: left; width: 125px; } form dd { margin-left: 125px; } form .buttons { padding: 2px 0px 2px 125px; } form .even { background-color: #ccc; }
HTML:
</p><form method="post"> <dl class="odd"> <dt><label for="reg_username">Username: </label></dt> <dd><input id="reg_username" name="reg_username" type="text" /></dd> <dd class="note">This is the name which you will use to access the application</dd> </dl> <dl class="even"> <dt><label for="reg_screenname">Screen-name: </label></dt> <dd><input id="reg_screenname" name="reg_screenname" type="text" /></dd> <dd class="note">This is the name which will be displayed to other users</dd> <dd class="note">If you leave this blank, then your username will be shown instead</dd> </dl> <dl class="odd"> <dt><label for="reg_password">Password: </label></dt> <dd><input id="reg_password" name="reg_password" type="password" /></dd> <dd class="note">Passwords must be more than 6 characters long</dd> </dl> <p class="even buttons"> <button>Register</button> <button>Cancel</button> </p> </form><p>
There maybe a little more markup now because of the lists, but we have now inextricably linked the extra information about each input to the relevant input.
Of course, how any browser uses this semantic link is beyond the control of the site developer, but this form will display nicely in any browser now, and not a single table in sight.
