Comment by anonymars
4 days ago
I will never understand the bizarre scene of the web's smug collective declaration that tables were dead and not to be used juxtaposed against the years it took to regain the ability to reliably center things. Assuming one agrees that we even did regain it.
Related: I also love when I can't paste tabular data into Excel/etc. anymore
For the record, I don't hate the idea of stylesheets, but...sheesh
> Related: I also love when I can't paste tabular data into Excel/etc. anymore
Except that’s exactly where tables should be used. So if you can’t, someone has really misunderstood CSS.
Use it for tables, not for layout.
I’ve gotten in several arguments over the years where webdevs insisted on showing tabular data using flexbox or hardcoded div widths or worse. They insisted that html tables were never ever to be used and couldn’t be persuaded.
If you try to render tables with millions of cells the browser does a really poor job and the performance is abysmal. The only solution when you need to render that many cells is to virtualize the table and only have the visible cells (plus some buffer) actually in the DOM at a time. That plus weird restrictions browsers put on certain table elements (looking at you thead) that prevent them from being "sticky" headers means that the developer is left with absolutely positioned divs as the only solution. Blame browser vendors for not providing a native way to present tabular data with more than a few hundred thousand rows without causing performance issues.
1 reply →
In fairness, the default `display: table` setup is often a pain to work with, so I can understand why people would opt for flexbox instead. One better option, though, might be to use `table` elements under the hood, styled with `display: grid` (and judicious use of subgrid for the intermediate elements) to get more precise control over the layout, while still using the right semantic elements underneath.
They are wrong, and didn't get the point of separating semantics and presentation.
I agree, but it is funny to me that your Hacker News comment is itself a table. It's in the same vein as "don't freak out, but there's a spooky skeleton inside you!"
I think it was advised a bit too early, but ever since flexbox entered the scene, tables for page formatting became irrelevant.
And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.
Do not use flexbox for page layout. It invites nested flexboxes, which eats your reflow performance.
Use grid instead.
Not the first time I hear of this, but I thought it was a blink-specific issue when using severely nested structures (e.g., html pages written using visual editors like Elementor or Webflow)?
For quite a while, I had to keep using flexbox instead of grids, because grids killed performance, funnily enough. That seems to have been rectified with modern browsers though, funnily enough.
Flexbox is great and having nested flexboxes is also great. It makes building responsive pages a bliss. Learn it if you are having trouble with it, it is really not that difficult. Grids are much more error prone and allow for much less flexibility.
1 reply →
Useful insight: any sources?
6 replies →
Even for layout, CSS took a long time to catch up with tables in some areas. Tables were not designed for layout, but there's a lot of aspects to them which are easier to grasp and work with than trying to get the same effect with early CSS.
They shamed everybody into the torturous use of floats for layout and then eventually, about 15 years later, added layout features back into a layout language.
I try to politely debate the proponents with each hype cycle giving them the benefit of the doubt. They lost the "lets get rid of tables" debate quite miserably. I would quickly slap something together in jsfiddle, they would try recreate it. Adding some col- and/or rowspan programmatically for cells with the same value. Give an rgba color to rows and nth cells (columns). Resizing columns by size of cell content. It took tons of ugly css to replicate. Pasting the table into a wysiwyg editor is something they can never hope to re-create.
Usually I declare victory when they say that tables might get depreciated in the future.
They at one point really wanted to get rid of framesets. I asked how to make the classic scrollable resizable side top bottom UI in pure CSS. We've tried for hours, everything we tried looked ugly and didn't fully work. framesets are here to stay now :)
I still have one of the funnier "how to make this without tables?" challenges. It's not a very good example of the use of tables but did make me laugh.
https://go-here.nl/omg-tables.html
>Give an rgba color to rows and nth cells (columns).
that sounds like a use for tables, so I find it difficult to imagine a non-table layout that would want this.
>Resizing columns by size of cell content.
I can sort of see this as a requirement for non-table layouts that would not work well, however my experience from table time was that was one of the biggest irritants at least for me, that columns would haphazardly resize based on what was in them, and sometimes you wanted them to and sometimes not. As a general rule I found it better design wise to truncate text rather than have things expanding and contracting in response to what copy editors were doing.
>framesets are here to stay now
woo yeah, I see them a lot in the wild. I mean really the only time I really see frames used anymore are iframes and generally in eCommerce and similar security requiring solutions where the frame can be partially controlled by the storefront, but is more fully controlled by the payment provider. I just find the statement "framesets are here to stay now" really weird and triumphal for something that is so rarely used?
>I still have one of the funnier "how to make this without tables?" challenges.
I followed the link, I would think it is better suited to a "why would you make this" challenge. I'm not sure
1. it shouldn't be a table. seems like maybe it should be
2. why the freaky animation. or for that matter why the animation nearly crashed my browser.
I'm definitely sure lots of designs could not be adequately achieved without tables and framesets, but my experience seems to have run contrary to yours because for me CSS was a godsend in fixing the things I found irritating about those two technologies, this does not mean that I never encountered situations where I thought this would be easier with tables, but as soon as I tried putting tables back in I found all those irritants came back in.
From my experience tables and framesets were best suited to layouts that are rarely ever wanted, and when used to implement slightly different layouts had too many problems and irritants to be useful.
Your mileage has obviously differed, but I'm not sure that "here is a particular problem that people seldom wish to solve and which I have constructed, that plays to the strengths of my favored technology while avoiding its pitfalls" is as impressive an argument as you seem to think it is.
> I will never understand
I think it's fairly easy to understand if you understand what it was a backlash against. Tables today are used sensibly, for the most part, but the pre-CSS world was truly absurd in its table use.
The reaction may well have been over-the-top, but it wasn't disproportionate given the state of table usage at the time.
CSS's initial forays into layout seem bad today because people think of tables in terms of their intended use (not the now long-gone monstrosities the community actually extracted from them), but in comparison to the previous ecosystem, floats were a relative godsend.
Tables as a layout primitive are fine. Lots of modern layout engines are based around vstacks and hstacks, which are just single table rows and columns. Most paper forms use a 2d table layout, and newspapers arrange their articles in a 2d table layout.
There were some reasonable concerns. Using tables for both layout and literal tables removes semantic meaning, nested tables can get complicated to layout, and layout the whole page as a giant table makes it difficult to adapt to screen size. But the first could easily be solved by adding a tag that works exactly like table but is for layout, the other two are about overuse of tables in the absence of viable options. We could have easily kept table layouts for the parts where it makes sense and augmented it with something css-like for the parts where it doesn't.
> There were some reasonable concerns. Using tables for both layout and literal tables removes semantic meaning
The simple solution:
<table type="layout"> (or "data")
Thanks, I was going to say the same thing. The developer cultural context, back then, really matters.
This is somehow worse than "never use goto"; because there are plenty of good uses for tables, and CSS was lacking features for forever after the clowns declared "tables bad" and the other clowns followed without thinking
The killer argument at the time (and even now most likely) is that screen readers could not distinguish whether the table was used for layout or for data and therefore sight-impaired users would have trouble.
The argument doesn't make sense because it is not too hard for a screenreader to understand whether a table is used for layout and even if it was hard the problem would more easily be solved by just adding an attribute to the table to indicate that it is used for layout.
Tables aren’t dead, they never were… when displaying tabular data. When it comes to layout I think you might be wearing rose tinted glasses. Remember having to put a 1px image in a table cell to avoid it disappearing? Remember “best viewed at 800x600”? I’m personally not nostalgic for either.
For what it’s worth, the very page we’re on here still uses tables and spacer gifs, in 2025. (EDIT: I don’t mean to imply that this is good, just an inescapable observation in this context)
Probably why there are endless reworkings of the site.
1 reply →
There were better solutions to those problems than the CSS debacle.
> Remember having to put a 1px image in a table cell to avoid it disappearing
Isn't this a trivial problem to solve that doesn't require introducing any new layout mechanisms?
at least they were specific
Today it's usually implicitly designed for iphone, designed for 1080p, or ipad, and you have to guess, strong correlation with whatever device the designer uses in his personal life.
...no? Today's sites use responsive design and adapt to pretty much any screen size.
1 reply →
My favorite part about that is how we came back around to display:grid
Until then, display: table kept everyone calm.
No, dealing with tables was like trying to build a house out of tempered glass.
With css grid, I can tell each element which area or column+row to occupy.
If I add or remove a random element, the rest of the elements stay in the correct place.
But do that with a table and you end up trying to glue your house back together shard by shard whilst trying not to cut yourself or breaking things more.
3 replies →
sidenote: as a teen, i would regularly layout posters and presentations in excel.. the page preview dashed-border and the grid stability was such a relief compared to word
On commodore 64 the screen is just a fixed size grid of characters. No one ever had issues making an ui. We pretend but flexible viewport size is not actually possible. If you are making a painting for example the size of the canvas greatly influences what can and can be done.
I made a stunning landscape photo one time that looked great only when displayed at roughly the size of a hand. If made larger undesirable details became visible (littering), when smaller important details were lost (a formation of birds over a fishing vessel).
> We pretend but flexible viewport size is not actually possible.
Not beyond a point, but it's still very useful to be flexible up to that. For example, I'm very grateful that a web page will reflow text rather than print everything on one line and force horizontal scrolling.
4 replies →
> the ability to reliably center things. Assuming one agrees that we even did regain it.
Is there anyone who does not agree that we can reliably center things in CSS nowadays?
At least one person. https://tonsky.me/blog/centering/
Haha fair, we do still suck at properly centering text, I'll give you that.