As a systems guy who only occasionally pokes his head into this web stuff: have we now completed the circle? For well over a decade I've seen generations of web hackers rail on about the evils of tables for layout. And now I look at this thing, and... it's a table. For layout.
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>?
CSS Grid isn't about replicating the table experience, it's closer to native support for css grids like bootstrap etc.
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.
That separation between markup and presentation language (CSS here) is exactly the point. Kicking all this stuff out into CSS means your markup can mean what you're trying to say.
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.
Why must a table be used in such a way, only for tabular data? Sorry if I seem obtuse, but I don't really see the purpose behind semantic elements. Tables were fine for layout with much fewer things that you needed to get right. Wikipedia still uses tables for the layout on the Main Page, for example.
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.
As a developer who somehow survived the times of frame, imagemap, and table-based layouts, I can promise you, they all had their own issues. Well before semantics, developers and designers needed CSS just to make things possible.
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.
HTML is not just about putting text on a screen. It is markup; the tags and attributes imply meaning about the contents they contain.
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.
Well, considering that the table layout has been available in CSS (without the 'baggage' of poor semantics) for a while (display: table-cell), CSS Grid and Flexbox must offer new layout options, which it does.
Apart from the semantic issues that result when littering your HTML with <table> tags that inaccurately represent the content they contain, Grid also provides features that tables cannot do:
* 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
It also provides everything a table does with far less code and easier to read markup.
You're assuming HTML, CSS, etc are created/optimized for conveying information. They are in fact optimized to sell books, conference tickets and generation of page views. Iterating on versions, technologies, etc is a wonderful way to make money without ever exposing yourself to the cruel reality of solving problems. You have to hand it to them - a brilliant, if obvious strat.
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?
>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?
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."
Tables are for tabular data. The layout functionality is perfectly fine for layout, but the fact that you're semantically describing the page contents as tabular data goes against the original intent and meaning for the <table> element.
So... and I swear I'm not being as glib as I sound: The only reason Grid is OK and Table isn't is adherence to the design intent of a 25 year old SGML hack?
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.
This is a very fair point. For instance, you can't do the sticky footer Flexbox example with a table layout: https://philipwalton.github.io/solved-by-flexbox/demos/stick... (or, at least, I can't immediately think how you'd do it, but hey, it's late, and it's been more than a decade since I've used tables to lay things out...)
Honestly, I almost just want simple tables back... It really feels like we've been working very hard to create more complex layouts with flex/grid systems, and while I can see the need in some cases... I can't help but feel a lot of the more trivial things would be better with simple table.
You can still use tables and CSS display:table (you should use the latter if the content is not actually tabular data so as not to make life annoying for people using screen readers).
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.
Oh, I very much agree... but I recently took the time to come up with a nice layout using flexbox (really my first time delving in without relying on a framework for most of it), and it wasn't too bad, some of the naming conventions are weird. But then I pull it up in IE11 in a VM and Safari... man, those were painful to fix. Yeah, I was maybe missing things, or the defaults aren't as sane as they could have been.. but Chrome and FF looked/worked great, but Safari in particular I had to redo things... then back and forth until it finally worked across the board.
In addition to the one-dimension vs two-dimension distinction, perhaps it useful to think of CSS Grid as for page/application-level layout, whereas Flexbox is for component-level layout.
Ignoring that they're for quite different tasks - Flexbox's (albeit crappy) support in IE11 makes it more appealing if I was going to pick one of the two.
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.
Simply because it's been the fastest and easiest way for me to vertically align stuff. Plus very backwards compatible. But I think I'm in the minority by not using the flexbox, etc.
If that works for you and your designs, then great! But there are a lot of places where display:table falls apart, especially with responsive designs. Flexbox and Grid also bring a new level of ability to separate source order from display order, which isn't possible using display:table.
You'd be forgiven for thinking, logically, that something which works in two dimensions would do everything that something which only works in one dimension would do. Unless the two, in fact, were intended for entirely different purposes, in which case the dimensions would be irrelevant.
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.
Rachel Andrew has added a very illuminating comments to the article which, I think, highlights why Flexbox can't do what Grid does:-
“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.
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/
Looking at the CSS Grid examples, I am not sure why? Tables and Divs with reflow can do the same, but with more predictable outcome and less boilerplate.
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.
Tables absolutely have their place... for rendering tabular data!
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.
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>?