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>?
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.
* 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."
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.
CSS Grid is a two-dimensional layout mechanism. CSS Flexbox only handles a single dimension.
I'm not sure the process which has resulted in both CSS Grid and Flexbox was really much grounded in logic (or common sense), though.
>it's not impossible to make multi-dimensional layouts in just Flexbox
Both are 2D layout mechanisms. You can make Grid act like Flexbox and vice-versa but they have different strengths, and are best used in tandem.
“Potentially Confusing: a “2D” Layout with Flexbox” – that isn’t a 2d layout. It’s a wrapped flex layout. As soon as you want to make that final box line up with the boxes in the first column you realise what you have isn’t two-dimensional.
Flex wrapping doesn’t make it two dimensional. Each row (in your example) is a flex container itself, space distribution happens across each row individually. Which is why it isn’t two-dimensional.
More here https://rachelandrew.co.uk/archives/2017/03/31/grid-is-all-a...
You can also space grid tracks out evenly and so on, box alignment is shared by both the flexbox and grid specifications. For examples of that see http://gridbyexample.com/video/align-grid/
But for those of us building sites with complex layouts (and situations where we can't be entirely sure of the contents, e.g. using a CMS or static site generator), it's really amazing to finally have tools in CSS to actually do page layout.
.mytable{display:table}
.myrow{display:table-row}
.mycell{display:table-cell;vertical-align:middle;}
How about optimising the existing render-paths even more in Blink/Webkit/Gecko instead requiring us to wrap the head around new-but-old things to make it easier for you (the engine devs). Or who else thought it's a good idea to invent yet another syntax. There was a lot of unfounded hate against Tables for the last 15 years, but as we all learned out, Tables have there place.
The idea that tables are "bad" was always semantic FUD, but i like to think we're pretty much over that these days and the fact remains that they're far from ideal for responsive page-level layout and we now have a far more powerful (and meaningful!) toolbox to pick from. The CSS display-table techniques were at best a hack, disguising the presence tables in the markup, but they were still there at an abstract level in all their tabley glory.
The stuff you can do with a handful of lines of flexbox/grid blow a conventional table layout away at the expense of a steeper learning curve. They're honestly worth the effort.
IE11 still has more users[0] hitting our main site than Edge, so I can see legacy support dragging on for a while yet.
But as pretty much everybody has noted, they do different things so this is more of a hypothetical comparison.
[0] Just checked - Edge 2.9%, IE11 4.2% of ~1.6m visits so far this month.