Well grids aren't essentially tables. I'm surprised by the comparisons here, it seems like many people have worked with either tables or grids, but not both. I frequently use both grids and table layouts along-side each other.

Tables are especially helpful for creating a horizontal list of elements that are evenly spaced, but of uneven/unknown width. You can't do that with a grid. Since grids are floated, it's easy to adjust the number of elements in a row (by either changing the width or the row or the width of the items). You can't do that with a table, since each row has to be delineated in the markup.

I don't use table elements for layout of course, I use display:table. Using a table element for non-tabular data would be unsemantic, unlike using a div which carries no semantics.

Grids would generally be worse - no semantic info like 'thead' or 'axis' in grids/divs. That said, I'm a bootstrap span fan and don't like this extended naming from the article - reminds me of YUI grids from several years ago.

But hey, "they're' not tables - tables are evil!", right?

RANT: I worked with some people ... sheesh - almost a decade ago that proclaimed "tables are depreciated" (I'm pretty sure they meant 'deprecated') and spent days having a team of people convert tablular data from Excel spreadsheets in to bloated DIV-hell for IE5 and NS4 browsers. That's been my worst experience with table-haters, but it stuck with me.

Could you not just send them a link to the specs? (and a dictionary)

I didn't last too long there, and thankfully I wasn't on that team directly. Yeah, pointing out things like 'facts' with 'evidence' doesn't make you a 'team player' very often. Yes, there's the issue that I'm the new guy, but really... there are some things that are objectively true. HTML tables have never been 'deprecated', have their place, and are perfectly fine. DIV-based layouts are fine too, but knowing when to each is key, and displaying hundreds of pages of spreadsheet-style data with inlined styles for each div is... just insane. They had to do inlined styles on each div because some version of IE didn't handle the formatting they wanted properly - some alignment issue - when I pointed out that table cells already supported that formatting... I think that's when I was no longer required to be involved in that project.

Because you want to split your page content and main structure from your design. If you really don't care about that, mainly because you will never change the design in the future and it's a small project, then do use table.

(Look at HN's code source)

Also it's worth noting that most codes using Foundation or Bootstrap are considered bad code for the reason I just told you : You're not supposed to have elements of design in your html page.

The correct way of using Foundation/Bootstrap would be to use mixins directly in the .scss files of your site (if you're using foundation, bootstrap should use LESS files and I have no idea how it works).

The grid is supposed to guide the visual layout and structure of the page. There's no real reason that it has to be encoded into the markup as we see it in the article except that it's much simpler to implement it that way.

For what it's worth, I tried searching for "semantic grid system" and found http://semantic.gs. I don't really know if it's any good but I like the idea.

A grid isn't essentially a table, and only the twisted history of web design could ever make someone say that. Imagine a discussion about book layout or poster design that made reference to grids and someone saying "oh so it's basically a table of data!".

And since it isn't a table of data, the grid is more semantically correct. Not because the grid has any semantics itself, but because you're not misusing other semantics.

Let's say I want a two column layout that takes up the full width of my page with each column taking up half the space. Using tables and no grid, I'd have to do something like:

    <table width="100%">
      <tr>
        <td width="50%">Column 1</td>
        <td width="50%">Column 2</td>
      </tr>
    </table>

I'd also have to adjust the border spacing and cell padding in CSS or as an attribute on the table because the default style for tables in every browser I know of adds them by default.

Compared to using a grid system (12 columns for the sake of example):

    <div class="container">
      <div class="span6">Column 1</div>
      <div class="span6">Column 2</div>
    </div>

One less nesting level, but no big deal. Now, let's say I want to have a responsive design whereby if there isn't enough room to display the columns side by side, the second column will reflow to be below the first. With my grid, all I have to do is add a media query to my CSS: my markup can be left untouched.

With the table, well, you're out of luck. The table markup determines layout, and you can't reflow table columns to make them table rows using CSS. I suppose you could use some JavaScript to rewrite the table on the fly, but just using a grid in the first place seems a lot easier.

Another benefit of a grid is that if you do care about semantics, you don't have to use meaningless divs: you can use any block-level element. This would work just as well as the grid example above:

    <body class="container">
      <article class="span6">Column 1</article>
      <aside class="span6">Column 2</aside>
    </body>

With a table-based layout, if you want to take advantage of semantics, you'd have to nest those inside each of the tds.

A third example: let's say you have the two column layout, but you want to dynamically add or remove the second column. If you're using a grid, no problem: the second column can be hidden or shown without affecting the first column's width.

If you're using a table, the first td will reflow because table columns will take up the entire width of the table. To get the same effect, you'd either have to adjust the width of the table or remove the contents of the second column's td instead.

The above also applies if you just want to change the width of the second column: if, say, you wanted to make the second column 25% width and leave the first at 50%, it's no problem with a grid: just change the second column's class to "span3". With a table, if you change the second column's width to 25%, the first column will expand to take the rest of the table's width. You'd either have to add a third td as a placeholder or resize the table itself.

There are a lot of use cases like these where having a grid winds up being a lot simpler than using a table. The benefit of a table-based layout was that creating a cross-platform grid was hard, and there wasn't a whole lot of prior art, so a lot of times you might have to start from scratch. But if you already have a grid-based system available, there's not much point to forgo that and use a table.