[SOLVED] Tabular Data ... what it IS and Isn't?

[dbrimlow]

Okay, this one is for the advanced HTML/CSS mavens here.

 

When we talk about using tables in our web pages, we all know that using them for LAYOUT is wrong, and using them for "tabular data" is right.

 

I've created a few real estate sites and have used floated boxes (with fixed sizes) to display the results of a search query. While it works, it only works using fixed widths and heights to keep the boxes equal in width and height.

 

I've been trying to create a "liquid AND elastic" design that would let me have cross-browser "equal height boxes" (the IE bane of us all ... but SOMEONE will eventually figure it out, so I've tried).

 

But today I realized something ... the search query results IS tabular data!

 

So, I am now trying to decide if using a table to display the results portion of the query is, in fact, proper. My full-time job is web admin for a huge real estate firm. I have slowly been converting the site to valid css over the past two years, and am now ready to plan out my search query results page (currently validates HTML "transitional", yet uses deprecated markup and is totally table based layout).

 

When a user searches for an apartment, they enter in their search criteria (price, location, size, etc.)

The results page displays all of the apartments that meet this criteria - starting from highest price to lowest ... and this is the result:

 

 

That looks like tabular data to me! There are some column and row spans. And that's where I am unsure of the legitimacy of using a table.

 

The photo spans three rows, but is clearly the data for the "PHOTO" column.

 

The "details" link in the "LISTING#" column is not part of the database data - although it is directly related to the listing# and links to the full page of that listing#.

 

The "add to inquiry" link is also "related" to "CONTACT" since it adds the record to the email that requests more information.

 

The one that is clearly in question, however, is the text description. While it falls within the three rows that make up the column for "location / description" it spans into the "PRICE" columns.

 

In order for the tabular data record to be legitimate within a table, does:

 

a. each record have to comprise one table row?

b. have no fields span two columns?

 

I can't get a clear answer when I google it.

 

Dave

 

 

 

 

 

[ToonMariner]

tabular data indeed  fits the requisit of one row/column per data set but that doesn't mean you can't merge certain cells - so long as it all makes sense you are fine.

 

In this case however I don't think you should be spanning cells for the description/price that is actually a layout or styling issue NOT a structural one.

[AndyB]

It's tabular data, but ...

 

I suppose the true test of whether it's tabular data properly presented (in the structurally-compliant sense) would be to ask can you actually include the full set of table tags and still have it work, e.g. what happens when you use the TH tag?  You'll find you have instances of two distinctly different pieces of information in the same TH, and semantically that makes no sense.  How would a screen-reader handle it?  Poorly, I'd say.

 

 

[ToonMariner]

agreed - in fact the only cells I would ever consider merging are header cells (where you can spilt something further ie. City - London - Paris - Melbourne. City would span 3 columns. the other headers would then span 2 rows!!! - hope that made sense)

[dbrimlow]

I suppose as soon as I realized I'd spanned a header, I KNEW it wasn't tabular data anymore.

 

I can most likely make a shaky case for spanning rows. But Andy put it into the best perspective.

 

Accessibility was the first reason why tables were frowned upon as a layout technique.