[e12e]

It's not. There were a few arguments against "table layout", some of which apply to hn as well IMNHO. Added tags without semantic value (just as your div-soup above also illustrates). Layout speed (in reality not much of an issue now - and also an issue with deeply nested tags with complex layout).

Both are fixed in modern html5 which moves (back) towards simple, semantic, document layout (html-body-article-heading-etc).

With flex-box layout it's also quite easy to have the article/main content come first (possibly preceded by a header) - followed by sidebars and footer -- all as their own "top-level" boxes/containers.

In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.

And finally table layout is generally verbose and messy for other types of content than tabular data.

[einr]

I look forward to trying modern flexbox and grid layouts. I have not had the privilege (?) to work with either yet; our customers are not necessarily on the bleeding edge of browser releases so I have to stay a little behind the curve. Hence, a lot of div soup and ridiculous indentation levels.

Honestly, for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere) a Bootstrap-style div layout gets at least as verbose and messy as a table layout would. I especially hate having to always do HTML comments with class/id names after every </div> so I know what closes what when I'm near the bottom of the file. At least with tables you get </td></tr></table> instead of </div></div></div>.

But of course a div layout is at least partially semantic and mobile/small screen friendly.

In a classic table layout, there's an extra top level element in addition to "body" - the surrounding table.

In practice, any bog-standard div layout today has a <div class="container"> at top level which contains nothing but other divs and sets size and positioning for the whole page. This is roughly equal to a <table>, no?

[e12e]

> for what I'm doing (a pretty complex web app with an almost desktop-style GUI with a bunch of buttons, text inputs and checkboxes everywhere)

Right. There's different contexts between an application an a (hyper)text document.

What's good semantic markup for one, will generally be bad for the other.

It's admirable (and desirable) to strive for adaptive layout and accessibility in applications - but they need a different type of framework than documents made for browsers. The browsers straddle this divide rather uncomfortably - being in part hypertext document browsers, and in part virtual machines for running general applications.

Approaches like web components[1] might help us move toward a standardised reality for "applications that happen to run in the browser", while css and html are still (more and more anachronistically) (hypertext) document markup and layout tools.

If you want to make a Web page/site (like alistapart.com) that's great. Swim with the current and draw inspiration from stuff like css zen garden[2]. With flex box, you can burn[4] most of the old complicated grid layout stuff, and comparatively easily make great sites.

That doesn't really help if you're a "front-end developer" making "apps" though. Even the few that make an effort to color within the lines are still fighting the browsers and the standard, trying to fit a code-on-demand app into a REST shoe[3].

[1] https://www.webcomponents.org/

[2] http://www.mezzoblue.com/zengarden/alldesigns/

[3] https://news.ycombinator.com/item?id=13500635 (I've said it before - the true tragedy isn't that too few read Fielding's thesis and never understood REST - It's that so many ignore that he covered a lot of other architectures that are more suitable for many applications than REST is)

[4] https://philipwalton.github.io/solved-by-flexbox/demos/grids...

[e12e]

The "container" is common, but typically not needed.

Sometimes it's a redundant stand-in for "body > .content" or similar (eg: divs dropped directly in body) - and is prevalent because developers don't understand and care about css selectors (or there's that one person on the team that doesn't -- don't get me wrong -- I realize the real world is full of real co-workers, and making a change isn't always easy).

And partially it can be an artifact of abusing floats for "grid layout". Most typically though, the "container div" just ends up being a completely redundant extra "body" element.

[return0]

oh yes! </div> is my nightmare. at least with table u can more easily spot the error when rendered.

> of course a div layout is at least partially semantic

That's contestable, <div> nowadays is absolutely unpredictable, <table>s are more semantic

Sometimes i wish HTML was like python hehe