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.
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?
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...
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.
> 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
<div class="container"> is one of my least favorite things to see in HTML, in particular. No shit it's a container; all HTML tags are containers. HTML5 introduced all these wonderful semantic elements precisely so that we don't have to pollute HyperText documents with thousands of divs.
Also, that "text-center" class drives me to drink :)
It's a standard component of Bootstrap ;)
<div class="tree">
<ul>
<li>
<a href="#">Parent</a>
<ul>
<li>
<a href="#">Child</a>
<ul>
<li>
<a href="#">Grand Child</a>
</li>
</ul>
</li>
<li>
<a href="#">Child</a>
<ul>
<li><a href="#">Grand Child</a></li>
<li>
<a href="#">Grand Child</a>
<ul>
<li>
<a href="#">Great Grand Child</a>
</li>
<li>
<a href="#">Great Grand Child</a>
</li>
<li>
<a href="#">Great Grand Child</a>
</li>
</ul>
</li>
<li><a href="#">Grand Child</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</div>
Side note: the top-level div isn't really necessary; you can just apply the `tree` class directly to the `ul` with a small tweak or two to the CSS.
To illustrate how HTML so ill suited to this structure, I had another look at the problem and found Treant, because yes, the easiest to do this on the Web and maintain it is to write an entire API.
I googled for a solution that I could add to and maintain myself and this was what The Internet threw up as the best solution, but it is far from good.
<ul>
<li>
<a href="#">Parent</a>
<ul></ul>
</li>
</ul>(But then you'll hit a wall as you try to deal with the containers and subcontainers.)