In general I like CSS, but ...

a) they keep on making CSS more and more complex. You can reason in favour of it, of course, but it is undeniable that CSS becomes more and more complex - and complicated, too. Which leads us to b)

b) "CSS Subgrid is a good example. Subgrid is a super-powerful extension to CSS Grid which enables entirely new layouts."

Well ... I wanted two flexible divs side by side. It is possible, but there are like 5 different main strategies for this, grid is one of them.

Now via a "subgrid", they acknowledge that the existing ways SUCK. So they add yet-another-component here. This reminds us of:

https://xkcd.com/927/

I started to go back to oldschool - HTML tables.

People can hate it, but they work really almost flawlessly. I am not saying I use them for everything, but I totally changed my mind after I saw how flexbox and other things SUCK to no ends. So I now compare all of them to HTML tables. If they suck more than HTML tables, I discard them. This is my quality metric now. And a lot of this has to do with developers making these decisions, failing hard at DESIGN. What happened to simplicity? HTML tables are simple for the most part; they are kind of like a grid already.

▲

DarkUranium 2 hours ago | parent | next [-]

Apparently, one of the very first proposals for a CSS enhancement was to use Cassowary-esque constraints for layout[1,2].

Think Apple's AutoLayout and similar, but in CSS. I don't recall why it went nowhere (though I do remember the reasons were more political than technical), but imagine CSS without all of the float/flexbox/grid/subgrid/etc crap, but just: `#table-a[width] == #table-b[width];` and so on. And no need for hacks involving deep `<div>` trees just to get the HTML to cooperate with CSS --- it breaks the whole "HTML is for content, CSS is for styling" premise anyway, when HTML needs to adapt structurally to CSS.

The proposal even had `@import` and `@media` (the latter named `@precondition`) all the way in 1999!

There were some attempts at revivals (e.g. [3]), but they kind of went nowhere. Personally, I'm strongly considering using it for my own (non-web-related) UI library. CSS' base syntax is okayish (the way you define classes, reference elements, etc), and the basic rules like colors or text-related things have warts, but are ultimately okay --- but anything to do with layout is an absolute mess.

[1]: https://web.archive.org/web/20140911231410/http://www.cs.was... [2]: https://web.archive.org/web/20140911231410/http://gridstyles... [3]: https://web.archive.org/web/20140907130017/http://gridstyles...

▲

dsego 17 hours ago | parent | prev | next [-]

I wanted subgrid a few years back. Imagine you need to show 3-4 pricing cards next to each other. It can't be a table, the cards have padding, an outline, shadow, etc. Inside they have rows of features. But some of the items aren't just a single line of text, they wrap around, and you need to have the heights of those inner rows align between the cards. It's not possible without a subgrid or some custom JS code.

▲

OnlineTux a day ago | parent | prev | next [-]

Aren’t HTML tables accessibility nightmares?

▲

OuterVale a day ago | parent [-]

For data? There are some foot guns but they do intended job well. For page layout? Accessibility nightmare.

▲

DarkUranium 2 hours ago | parent [-]

I'm curious, why are they an accessibility nightmare for page layout? I don't use them for that, mind, but I am curious.

Plus making a webapp with accessibility in mind, and I'd like to be aware of footguns.

	▲	OuterVale an hour ago \| parent [-]
		It has been a bit since I've researched why tables shouldn't be used for layout so I'm not full bottle. Perhaps I'll have to write an article. Linear layout issues come to mind first: https://www.w3.org/WAI/WCAG22/Techniques/failures/F49 Then there are issues with screen readers and how they interact with tables. Tables convey that they are tables, so screen readers treat them as such. Sometimes this means reading headings in between cells to help orient the user, and sometimes it means they'll add numbers for orientation. A bit of detail here: https://dequeuniversity.com/rules/axe/4.1/layout-table If there are any mistakes in the markup, then it can completely throw off the layout in the accessibility tree without having any visual indication that something is wrong. Perhaps most importantly, tables are very rigid and inflexible, so if trying to do anything more dynamic or out of the boxy flow it usually means messy hacks. If you're really careful you can sometimes get away with it, provided your site is extremely rigid in layout, but it generally ends in an inaccessible mess that is inaccessible in ways that people don't even bother to document nowadays. Just use flex and/or grid if you're targeting modern browsers. Much easier to author and much better for users.

▲

zelphirkalt 18 hours ago | parent | prev [-]

Did you know you can make tables in CSS now ... ; )