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
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.
This complaint highlights how absurdly not fit-for-purpose html+css actually is. Okay, you may want to do "responsive" design, but you have the semantic layout fixed, therefore you try and contort a styling engine into pretending to be a layout engine when in reality it is three stylesheets in a trenchoat.
And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.
Use grid instead.
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.
I need to write this up properly, but one of my bugbears with responsive design is that it became normalised to push the sidebar down below the content on small screens. And if you didn't have a sidebar, to interweave everything in the content no matter what screensize you were viewing on.
What I want is a way to interleave content and asides on small screens, and pull them out into 1+ other regions on larger screens. Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.
This CSS Grid approach adds gaps: https://codepen.io/pbowyer/pen/azNarbZ
Using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them.
'Good' old floats get most of the way, but put the item in the sidebar exactly where it falls. Plus they're a pain to work with overall: https://codepen.io/pbowyer/pen/jEqdJgP
The most important thing is to use the right tool for the job. If grid lets you express what you want in the most straightforward way, use it; if flexbox does - even if it needs nesting - then use it instead. Don't shoehorn one into a situation where the other makes more sense. And sometimes either will work for a particular situation and that's fine too; use whatever you find most ergonomic. They're both very good in their own way.
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.
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).
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.
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.
this not fit for purpose may in fact be historically superseded usages that still are baked in to some usages affected by the relatively rapid change of the various platforms that must interact and use the respective technologies, the specification version of "technical debt"
that is to say some subsets of the numerous technologies can be used to construct something fit for the purpose that you are describing, but as a general rule anything constructed in a solution will probably be using other subsets not fit for that particular purpose, but maybe fit for some other purpose.
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.
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.
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.
Today sites certainly can and some (many) so. But some (also many) definitely don't…
A lot are locked to a maximum width, which is OK enough as l……o……n……g lines of text are unpleasant to read, but only because browsers hack the meaning of dimension settings to make text zoom work consistently.
A lot also have an effective minimum width (even if they use responsive styling to move/ minimise/hide side decoration before a certain point) that is not always convenient. Try browsing with a thin window so you can have something in the other side of your screen. Some assume no one on desktop will ever have a browser window less wide than 1280 pixels (or equivalent on a zoomed higher res screen) - not the case on my 1080p portrait screen and I sometimes want things thinner than 1280 on my 2560x1440 screen. You could say I'm just odd and they can't cater for everyone, but 1080 or a bit less wide is hardly miles away from many devices physical layout so if a design can't display nice in that can it really call itself "responsive" (I suspect any such design would fail on many mobile devices too - 1080px effective width is rather common there, as are smaller widths).
I'd argue that if you have so many rows that DOM can't handle, humans won't either. Then you need search, filtering, data exports, not JS attaching a faked scrollbar to millions of rows.
We are having a lot of fun pretending it is possible.
The simple solution:
<table type="layout"> (or "data")
Therefore, to calculate the size of an item, the sizes of other items need to be known. Now, if one of the items is a flexbox, its item sizes cannot be known until the previous flexbox is laid out.
Of course, properly using flex-grow and flex-shrink can optimize that calculation, but what about deeper nested flexboxes?