NYCPHP Meetup

[Rob Marscher]

I think the "proper" use of HTML tables is to display a list of things 
ordered into rows and columns.  As Chris Snyder pointed out in a 
previous post in this thread, you can use it for a form of labels and 
inputs, or for thumbnails and descriptions, as well as traditional 
tabular data, and I'm sure there's other good uses as well.

Personally, I've been able to get away without using tables for forms by 
using other html elements like fieldsets and labels and some divs or 
spans.  For thumbnails and descriptions, I use the definition list html 
elements (dl, dt, dd) where the thumbnail is contained in the <dt> and 
the description is in the <dd>.  That could be overkill though...  Some 
places where I've used actual tables are lists of search results where 
you have a column for each field in the result and inboxes for messaging 
where you have rows for each piece of mail.  Basically, my rule of thumb 
is to see what the html looks like with all the styles turned off (can 
do this by hitting ctrl-shift-s if you have that Web Developer Firefox 
plugin I recommended) and if it still makes sense, then things are good. 

If your trying to avoid tables for layout, it seems the main place to 
question yourself is when you find yourself nesting tables inside other 
tables or you have a table with one row or one cell.

-Rob

Kenneth Downs wrote:
> Rob Marscher wrote:
>> Usually if you avoid using tables for layout, you can drastically 
>> change the layout of your page without altering the html.  If you 
>> keep to the indended use of the html tags, then the page should look 
>> somewhat ok if you turn off your styles altogether (which is maybe 
>> how it would look for someone using Netscape 4 or some other ancient 
>> browser).  You can also supply different layouts for other uses like 
>> printing or for mobile devices without changing the html.  I think 
>> screen readers for visually impaired people read table html elements 
>> expecting it to be some type of data.  I can't say that from 
>> experience though.  So if you don't really care about those things, 
>> I'm not sure there's anything else wrong with using tables for layout 
>> except you'll have young "know-it-alls" who just got out of their 
>> html development class saying that you have really bad code (happened 
>> to me before).  You also can't put those cool xhtml/css compliant 
>> badges on your page ;)
>>
>
> Rob, this is actually one of the more persuasive arguments I've heard 
> for the DIV/CSS model.  You hear a lot of dogma about CSS, which has 
> led me to this conclusion:
>
> CSS is to HTML Tables as   Java is to PHP
>
> In other words, one of them was designed by a committee of thought 
> police, while the other lets me get my job done.
> Another argument I would have put against your reasoning is that I 
> don't drastically change my layout, once its delivered to the 
> customer, that's it.  However, your post led me to an Aha! moment, I 
> do in fact change layout drastically a lot, during *development*.  
> Until it is finalized we are forever tweaking it.  This makes it 
> worthwhile to experiment a little with CSS during layout of 
> specialized data screens, I'll let you know how it turns out.
>
>
> So what is the proper use of HTML Tables?  A form of INPUTs, with 
> caption on the left and inputs on the right, are table anointed for 
> this task, or Divs looking to do this one also?
>