(talks about a CSS/divs solution, but as it mentions there are differences between the two). In general if you're dealing with a design that involves centering something with a dynamic size vertically, or one which involves having the height or width of two dynamic elements add up to the width of a third adjacent element (ie. "rowspan" and "colspan" in table-speak), there's a decent possibility that using a table might just be the least-hacky way to implement something. Bearing in mind that hackiness is a bit subjective :)
Yeah certainly, thanks for the examples. I think the first item you mentioned, vertical centering of a single dynamic object actually can be handled better than tables currently (see some techniques here: http://html5hub.com/centering-all-the-directions/) but when you add more elements into the mix I can see how rowspan / colspan equivalents are not easily implemented without JS.
A main content area and a sidebar with each having different colors and both maintaining the same height such that they expand vertically with the content (without having to hard-code pixel values).
I saw a page showing how it could be achieved using only divs, but really, it was a complete rube goldberg machine, the sole purpose of which, seems to be to adhere to the religion of not using tables.
I get that table layouts have their own issues but I think its silly to be dogmatic about refusing to use them where it's clearly the best hammer to drive in that nail.
You're right, everything else I can think of is worse for data, tables are pretty good for that (minus the weird vertical centering thing that sometimes happens in cells.)
But seeing tables being used for layout annoys me far more than the blink tag.
> But seeing tables being used for layout annoys me far more than the blink tag.
How come? CSS positioning is pretty unintuitive, and sometimes it's just easier to get something working with tables. If the end results look fine, what's the problem? Table-based layouts aren't in-your-face like the blink tag was.
When I rewrote the Coursera discussion forums and sent them through an accessibility audit, I was told to use <li>s instead of <div>s to represent the nested conversations, which makes a lot of sense when you think about it. Disqus also uses <li>s for their comments.
So, just FYI, if you find yourself generating HTML for something like HN anytime in your life.
My problems are mostly how easy it is to get lost if you're dealing with nested tables within tables (especially inside templates), and that they have to be completely read before rendering... although that may no longer necessarily be an issue with modern browsers.
I find divs and spans easier myself but I guess, yeah, at the end of the day if it looks fine and it loads fine then it's fine. Too much pain from hand-coding too many tables has made me twitchy and curmudgeonly.
Oh, and don't view-source on HN ;)
Oh, i'm aware...
It's just too bad html doesn't provide elements that handle nested lists. If only. Ah well.
I've actually found CSS layout to be more intuitive than tables. maybe it's just that I have ages more experience with CSS than tables, but seriously, tables feel like a cludge for layout.
But why would you want that? The whole point of moving from <table> to <div> for layout was that using <table> wasn't semantic and was the wrong tool for the job. But <table> is the right tool for displaying tabular data. That's its entire purpose for existing. Using <div> to display tabular data is a regression.
I don't disagree, just pointing out that there are ways to achieve a tabular layout without an html table. Tables are for data right?
On the other hand, I like the idea of less and more generic constructs that can be adapted to achieve some need. Specialized tags like dd, address, details, summary, code, blockquote, etc just seem superfluous.
