Hacker News Reader

Comment by krapp | Hacker News Reader

<table> wasn't actually abused; it just happened to be the best way to do things until CSS 2.1 was rolled out.

There are still use-cases where using <table> is the cleanest way to achieve something without resorting to javascript (or a <div> soup tag).

Like what? I buy the use case of using a table for data, but are you implying there's other scenarios where using table elements are the best choice?

Email for one.

I get it but I feel that's more of an imposed limitation by email clients and not a fair choice.

Here's an example, for one:

http://css-tricks.com/centering-in-the-unknown/

(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.

Vertically centering floating content is a PITA without this dirty, dirty hack :)

How else would you display data?

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.

Oh, and don't view-source on HN ;)

(views source)

as a <table> user, I feel vindicated :P

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.

Isn't <ol> <li> <ol> <///> Valid?

Yes, i was being sarcastic.

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.

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.

I believe discouraging the use of tables for layouts is accessibility based. Screen readers have a really hard time parsing them correctly.

I'm using SlickGrid[1] in an internal tool. It uses divs and spans to display data, so there are certainly nice examples that do so.

1. https://github.com/mleibman/SlickGrid

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.

Edit: typo

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.

That would break HN.

Nah. It's basically an unordered list inside a block, tables are entirely unnecessary for a layout as simple as HN's.

Reply on news.ycombinator.com