The major advantage is its flexibility and ease in creating responsive layouts that look good at every screen size. One example is the minmax property: I want all these products in a grid, large enough to fit all their names. If you have the space, make the bestsellers larger and include the description. Oh, and they should really line up vertically and horizontally.
There's nothing that was completely impossible before, but there are a million hacks that we can finally discard, like all the shenanigans I've had to play with negative margins over the years.
Using <table> elements should mean you're defining a table with tabular data in it. These new bells and whistles don't change that. You'll still use <table> for tabular data.
And I'm not sure what you mean about native app development. We bitch and moan about the inadequacies of CSS (more its implementation) but layout engines in real programming languages are a total ballache to get along with, especially if you're from a CSS background. You can't just commandeer a table and twist it for your own evil deeds, you have to use one of a finite layouts. Gtk3 is the closest I've found to something I didn't want to stab on sight.
I don't think there is any 'meaning' in the tags that we use, and any meaning implied there is invented as a way to try and match concepts on the screen to things we recognise in real life. I can mean the same thing to a user using tables, because they don't know that it's a table. Can I put a comment like "This table is for layout"? That would also convey meaning, and be a lot easier than messing around with CSS layout.
After a while of trying to get CSS to work with table-like layout, I think I'm going to move back to just using tables in future. At least, until something better than CSS+HTML comes along.
But you're focussing on people and healthy ones at that. Semantics matter a lot less there because you can style anything to look like anything else. But somebody with a screen reader literally needs semantics for accessibility. You set your page up as a table and their screen reader is going to iterate through it like a table.
And things like microformats are soft-semantics that allow your devices to explicitly know that "this thing here is an address", "that's a phone number you can click", and there's a whole bunch of formats for declaring embed data rather than making a service infer it from your actual content.
But if you just can't be bothered, do yourself and your users a favour. Use a framework (eg Bootstrap). It won't be perfect but it'll stop you using tables for layout and that's already a lot better. I can't believe it won't also look better.
This makes it not only usable by a web browser, but parsable by software. That includes, but is certainly not limited to, screen readers, assistive technologies, and search engines.
Consider an example where I use JavaScript to make <i> tags behave like links. I can make it “work”, but by doing so, I am disregarding—and breaking—a primary function of the language.
* overlapping cells (http://gridbyexample.com/examples/example15/)
* empty cells, without a bunch of empty <td> tags (http://gridbyexample.com/examples/example12/)
* size columns (or rows!) in proportion to one another
* complex alignment of contents within a cell (http://gridbyexample.com/examples/example24/ and http://gridbyexample.com/examples/example25/)
* specify exact min and max sizes for columns & rows
* provide a full definition of responsive behavior, often without any media queries
I can imagine the conversation in some disused conference room going something like:
Organizer: Guys, I think the jig is up, we literally have ran out of new ways to layout a page. I think the string is run on this con.
New guy: Why not just repeat things like they do in fashion? Y'know like bell-bottoms.
Organizer: C'mon these lemming-like developers are not that idiotic.
Old guy: We can always go more dumb. tables v2 it is.
I've often wondered if one reproduced a sample of web pages in OpenGL/C, and compared the compressed source to the equivalent HTML/CSS/JS source, which would be larger?
Yes, that's very good.
You don't have source order independence with <table> either.
I'm seeing a worrying trend in front-end dev towards things that are "nicer" to "read" but more difficult to actually reason about. I don't understand what benefit we're gaining for removing the relationship between the order of the source code and the order things are rendered. All I see is a negative (it's more difficult to find the place to make an edit later on).
As the other guy said: "Meanwhile I see that native app development continues, as it has for like 30 years now, to shamelessly put UI components directly into hierarchies based on physical layout. And they still haven't tripped over the paradigm."
For when things change, for when we want to reorder content without scripting. Why would having it as an option not be preferred?
Basically you're just restating the orthodoxy. I know the orthodoxy. I'm asking if maybe this is time to revisit it, and wondering if maybe the last 16 years of flamage were a mistake.
Oh sure, it's a table defined externally to the components. So your screen-reader enumeration of the document structure is unpolluted by the physical layout which is stored in a separate data structure in a separate language. And that's... good, I guess?
Meanwhile I see that native app development continues, as it has for like 30 years now, to shamelessly put UI components directly into hierarchies based on physical layout. And they still haven't tripped over the paradigm.
I know it sounds glib, but it's a serious question: tell me again what was wrong with <table>?