Is it OK to span *half* a table with a form?

Is it OK to span half a table with a form?

sneakyimp

I have a fairly complex layout for a page I've been working on. I just realized I'm going to need to put the last few rows of a big table into a separate form. Right now the entire table is enclosed in a <form> tag. Is it ever OK to span only part of a table with a form? Like this:

<table>
  <form namej="formOne">
    <tr><td>ROW 1</td></tr>
    <tr><td>ROW 2</td></tr>
    <tr><td>ROW 3</td></tr>
    <tr><td>ROW 4</td></tr>
  </form>
    <tr><td>ROW 5</td></tr>
  <form namej="formTwo">
    <tr><td>ROW 6</td></tr>
  </form>
</table>

I mean, I bet it will work but I'm wondering if it's 'valid' html ?

NogDog

Run it through the validator and find out.

sneakyimp

It doesn't fly under any version of html strict or transitional. The validator sayeth nay. Apparently overlapping of elements is not permitted--although technically the form is nested inside the table. Nested forms are also not permitted. sigh.

NogDog

Sounds like yet another good reason not to use tables for page layout.

sneakyimp

So be honest with me nog, you never use tables? I think I can picture the alternative - Divs with CSS styles placing things - but does the alternative work across the various browsers?

NogDog

The only time I use tables are when (a) presenting tabular data (the reason HTML tables were created) or (b) working within the constraints of a page layout schema developed by a client who is only paying me for back-end code, not for HTML design.

Once you get used to working with CSS for page layout, you find you can create page layouts in about the same amount of time as with tables (some take longer, some go faster depending on the type of layout), but page and site maintenance becomes a lot easier and faster. I cringe now whenever I go into some client's site to make a minor alteration and find myself diving into multiple layers of nested tables, trying to figure out where I need to insert one new table row/cell or such.

Note that there are those who argue that forms can be considered tabular data, consisting of rows of inputs divided into columns of labels and input fields. I have no problem with this interpretation; it's just when you start nesting tables within tables purely as a means of page layout that you are straying from the semantic meaning and purpose of HTML tables, making the page harder to maintain, and probably also increasing the time it takes to render the page (especially in IE, which will not output anything until it calculates all the dimensions of the table rows and cells. (It can also make the page difficult for text-to-speech readers or non-graphic browsers to output the content in a meaningful order.)

Weedpacket

sneakyimp wrote:
although technically the form is nested inside the table.

Well there's your problem. The list of elements that can appear as children of table elements runs "caption", "col", "colgroup", "thead", "tfoot", "tbody". You'll note that "form" is not in that list.

In HTML both the opening <tbody> and closing </tbody> tags are optional. Since XHTML doesn't have optional tags, and since so many tables have been constructed that don't mention the implicit tbody element, "tr" has been added to the list of elements that can legitimately be added to a table's children.

halojoy

🙂

Sometimes tables are good.
Remember, it is not forbidden to use tables.
It is perfectly valid XHMTL code, for example.

A sensible programmer will use tables and/or divs, where is a good idea.
Often a combination divs/table is really nice!

Restricting to never use tables, is to limit your own tools box.
To use many different tools makes your coding easier and gives more possibilities.
You can do more things and in an easier way.

This is, to me, being really smart.
🙂

NogDog

Sometimes tables are good.
Remember, it is not forbidden to use tables.
It is perfectly valid XHMTL code, for example.

A sensible programmer will use tables and/or divs, where is a good idea.
Often a combination divs/table is really nice!

Restricting to never use tables, is to limit your own tools box.
To use many different tools makes your coding easier and gives more possibilities.
You can do more things and in an easier way.

This is, to me, being really smart.
🙂[/QUOTE]
I am not saying to never use tables. I am saying to restrict their use to tabular data.

Why: Why tables for layout is stupid: problems defined, solutions offered
Inspiration: www.csszengarden.com (not a table to be found in any of the sample layouts here -- in fact, they all use the same HTML mark-up)

sneakyimp

I try very hard myself to avoid nested tables, etc. and I make use of CSS all the time. I have yet to see in these examples, however, how one might emulate the layout of a table (that nifty grid pattern) without actually using a <table> tag. I'm talking rows and columns. The thought of creating a DIV tag for each cell and giving it a precise height, w, x, and y sounds like a nightmare.

NogDog

sneakyimp wrote:
I try very hard myself to avoid nested tables, etc. and I make use of CSS all the time. I have yet to see in these examples, however, how one might emulate the layout of a table (that nifty grid pattern) without actually using a <table> tag. I'm talking rows and columns. The thought of creating a DIV tag for each cell and giving it a precise height, w, x, and y sounds like a nightmare.

Yep, if you want to emulate a table-based layout, then tables will probably be simpler to use. The question to ask yourself is whether you are designing your layout with tables in mind from the beginning? And again: if the data you are representing on part of a page can legitimately be thought of as a data matrix of some sort, then by all means use a table for that particular part.

But, as far as overall page layout goes, if you can "free your mind" from the constraints of rigid grid-based layouts and start thinking of columns and relative positions, there is so much you can do with CSS that tables cannot do, or at least not do without multiple levels of nesting, colspans, rowspans, etc. And the biggest benefit comes when you decide you want to change the layout of a multi-page site and, if correctly done in the first place, all you have to do is change one stylesheet file.

And just to be annoyingly repetitive, HTML tables are a legitimate mark-up option and have their place; it's just my opinion (and that of many others) that they are over-used for purely visual presentation means, which is not what they were intended for and can result in a number of negative impacts.

sneakyimp

So do you guys use strict or transitional?

NogDog

Strict all the way, baby! 😉 Preferably HTML 4.01 Strict, but XHTML 1.0 Strict if a client insists. (There is nothing wrong with XHTML and many good things, I just prefer to stick with HTML until some decade when all browsers catch up with the ability to receive and process true XHTML served as XML, rather than as HTML using a XHTML doctype.)

The only "good" reason to use a transitional doctype would be if you are working with an existing site that uses deprecated tags and/or attributes, and it is not within the scope of your job to convert it into an up-to-date implementation.

I realize it sounds like I'm being a "standards snob" of sorts here, but I've found with experience that following the strict standards, using meaningful and semantic HTML mark-up and keeping the visual presentation separate from the mark-up via CSS, really does have enough overall benefits to make it worth the time to master. And really, once you do master it, it does not take any more time to implement it. OK, sometimes it does when you get a design to implement from someone who was obviously thinking in terms of HTML tables, but you still usually save time in the long run when you calculate the time spent on site maintenance.