Hello everyone. I am all for tableless CSS of course. But I searched this forum for an answer to this, but haven’t come up with anything yet. I manage a site that I am converting to CSS layout, with a corporate personnel who have a presence on one of the pages. They are arranged in a simple grid in a table, with photo, name, email link and title.
I am wondering if this technically qualifies as tabular data. Does it qualify among the gods on CSS Olympia to leave this be as is. Or is this something that should be converted to tableless?
It is my opinion that that is a list. It is definitely not a table, even though it takes the griddish form. A table, by definition, has certain characteristics, for example: Each row is a record, and each column is an attribute of that record. Each column’s content will be the value of a particular attribute. There is a defined relationship between the values of each record, that is repeated (positionally) for each record.
In your example, it could be a table if e.g. each row were a department, and each column was a job description.
Seems like there is no definitive definition. I take it to mean that is up to the designer. I saw a quote from the W3C that says:
The HTML table model allows authors to arrange data – text, preformatted text, images, links, forms, form fields, other tables, etc. – into rows and columns of cells.
That’s what I have with the grid, rows and columns of cells.
Maybe, just for the experience, I will try to mark it up as CSS only, but I would not want to add tons of hacks and extra markup to achieve something that makes a grid, if that’s what tables are for and do it efficiently. I really need to avoid a nightmare situation as I am on the clock.
If that is, indeed, the case, then it is a table structure. I read it as each cell contained all the data on that employee. In that case it is not a table, but a list.
If I didn’t have any headers, I would make it a list, personally. Unordered.
I’d use a table if I had directions of information. How are these people being listed? Randomly, or by something like department?
Similarly I use lists for products in e-commerce. Each “cell” has no columnar or row relationship with the other “cells”, but are completely self-contained with their data… so they aren’t cells but list items for me.
One way you can tell:
if you take something that is real tabular data and try to just list each data cell in some unordered list, you would be missing information. If you’re not missing information, it’s not really a table, but if you need to add at least two bits of header information on every item, it needs to be in a table.
That’s how I read it too … a bit like a thumbnail gallery but with the caption for each photo having the name, title, contact details etc. If that’s the case then a table would be seriously wrong, because there is no spatial relationship between the cells. A series of <div>s or a <ul> would be better.
On the other hand, if there is a column of photos, a column of names, a column of email addresses etc, with each row providing the collected information for a single person then yes, that would merit a table structure. But IMX it’s pretty rare to go for that layout any time after about 1998, because more often than not it looks messy and wastes lots of space.
It kind of gets back to what I was saying. There is no definitive authoritative definition. Seems to me that tables were created because the authors of the earliest websites had no literally other way of presenting data in a grid, even data that repeats in both directions. They had no other way to do that, which is why tables were created.
My dad was a construction worker who said “always use the right tool for the job.” I think that is why table-cell was added to CSS, because they realized there was no real sane way of doing a simple grid without a bible of hacks, at least not one that I have found yet. But legacy browsers don’t accept table-cell right now. So, if a table to lay out a simple grid is more efficient and easier to update, in a team situation especially, then you are using a table for what it was created for, if there is no better tool. And right now, I know of no better tool for a small and simple grid, other than utilizing the 960 grid system for that one purpose, which I am not completely crazy about.
The argument goes back to “separation of content and presentation.” However, I’ve always thought that to not be the best term. A table is a presentation of data. When you have a bunch of words, and you put them into a table, so that they make sense to the user, that IS information design by definition, even if rudimentary, and qualifies as presentation, and it also is a layout. Even a website is a presentation of content.
A better term, that I think is more accurate, is “separation of content and styling” which isn’t perfect in itself but I think is more accurate. And if you are using tables for what they were meant to do, with styling separated, I think it falls into the above definition.
See, I disagree on that – if it’s tabular data, where everything in a row is related and everything in a column is the same type of data, that’s saying what the content is, NOT how to show it. While displaying it in rows and columns may be the most common approach, it certainly isn’t the only one – like say for braille, or teletype, or screen readers… or even on most non-droid non-Apple mobiles where table-cells won’t actually fit the screen so all TD are shown as display:block;
There are a lot of tags people think have a presentational meaning because of their name – table is one of them. Being a table of data and showing it as columns and rows are two separate things!
A great example of this is B and I – which is supposed to be used in the grammatical sense when something would be bolded/italicized without adding/changing the meaning (book title, company name, etc). How you present that it’s bold/italic is completely unrelated to font-weight and font-style, apart from it being the most common technique. This is as opposed to EM and STRONG which have the semantic meaning of ‘emphasis’ and ‘more emphasis’ – which are completely unsuited to putting around things like book titles.
Goes back to something I had in one of my old signatures – if you are choosing your HTML tags based on what they look like, you’re probably choosing the wrong tags!
As evidenced by not all user agents displaying tables as rows and columns… That’s why it’s called “TD” or “TH” (table data , table heading) and not “table columns”
In that way, the notion of separation of presentation from content along with semantic markup is hard for the visually oriented folks to grasp – just because it’s called something you associate with a visual presentation does NOT mean that’s what the tag MEANS.
I see what you are saying. Separation of presentation and content does work when thinking about the semantic code. But for designers, you are right, it makes little sense. Some people who use the term don’t even utilize the concept of semantics. Most of the time I have heard that term it is not in reference to keeping things semantically meaningful, but simply keeping the visual presentation data (ie colors of fonts and layout of the page) from being mixed the HTML. In that sense, I like separation of content from styling, because even a plain list is a presentation.
No, it isn’t. A list is a list – it’s what type of content it is. You are just saying what it is “a list” – you are not saying how it should be shown. Presentation is how you SHOW that list. While user agents may have a default appearance for them, that default appearance is not what it MEANS.
That’s the disconnect I think a lot of people cannot grasp about semantic markup and the concept of separation of presentation from content.
But the markup is not the content is it? Maybe that is where I am disconnected. I take CONTENT to be the the substance that the list markup arranges to be viewed by the browser as a list, the list tags are being the declaration of how that content should be treated. So the content is just a bunch of words. But when they meet with the <ul> tag they become order, thus giving us a presentation. Therefore, I have taken the word “list” to be the ordered presentation of an otherwise meaningless bunch of words and that the STYLING would be separated from the content and the HTML markup.
From what you are saying, it seems that the markup (ie <ul>) is actually considered part of the content. Maybe that is where my disconnect is and what my misunderstanding could be.
If you are displaying the data with the photos in one column, name in the next, email address in the third etc then its a table.
If you wanted to display multiple photos across the page with the name, email address, etc under them then you would have far greater flexibility in displaying different numbers of entries across the page based on the width of the viewport if you don’t use a table.
The width of the viewport isn’t a concern as it is a fixed width layout. The problem I am having is how to do a simple grid without using the table-cell value, but have it in a grid that can automatically adjust if the content changes (ie one of the images becomes bigger than the other) without breaking the whole thing and causing nightmares that cost dollars in fixing it in development. Like I said, the only option I can find is the 960 grid applied to a small part of the website so I can layout via css. But the 960 grid is not very semantic either.
Ok, that’s probably it. You’re taking “content” too literally as the text itself – the CDATA (character data) does not say what each bit of CDATA is. In that way, the HTML is as much a part of the content as the CDATA.
See, the point of semantic markup is to say what things ARE. If you have a second level heading and you don’t put the H2 tag on it – how do you know it’s a heading? That’s not “presentation” thats saying what that piece of content IS.
That’s the point of semantic markup – Saying what things ARE, not what they look like. In that way, H2, P, blockquote – are as much a part of the content as the text or images inside them!
Otherwise being a whitespace neutral specification you’d just have one massive run-on of text – the content then loses much of it’s meaning. It’s why truly presentational markup IS meaningless gibberish. For example: <font size=“+2”><b> instead of <H2> – doesn’t say what the CDATA is, just how to present it.
HTML is for saying what the CDATA IS (content), CSS is for saying what it looks like. (presentation)
Goes back to the whole reason TBL came up with HTML in the first place – to say what the content was so user agents could best customize that content for display REGARDLESS of the target device.
Yeah, that’s probably why HTML 5 has <article> and <header> to keep updating the semantics that HTML was meant to have. Good point.
So my thing is, if <table> and the stuff that goes into the table is content, then placing images (content) and text (content) into a table (content), to get a grid result, should be fine, even if they do not repeat in both directions, if the colors and padding etc etc (presentation) is left to the external sheet.
I mean if, rather than <table> the tag had always been <grid>, we may not even be arguing what is a table and what is not a table. Because if a table is content, it’s just a matter of how someone defines “table” for themselves as to what is appropriate to use that for. It becomes a matter of philosophy at that point it seems.
Not quite – are you putting them into a grid for presentation, or because the elements are RELATED on each axis? That’s why it’s a table. You want a flat ‘grid’ that’s presentation and probably has no business in the markup.
If all the TD across a row are related (the image for a user, the user’s name, their title, their e-mail addy) and all the columns are the same type of data (images, names, titles, e-mail) then that’s tabular data – the division into rows, the use of attributes like scope, the use of tags like TH, and even the caption tag are all saying what the data IS and how it’s related.
Using it just because you want a bunch of data slapped into a grid is missing the point.
Thanks!
