[graiz]

The problem with css is that it's a horrible design language, terrible from a developer perspective, and abysmal from a performance perspective both on the network-side, server and client side. In-fact it would be difficult to come up with a standard for transmitting information, layout and style specifications over the Internet in a worse and less efficient way.

Most web-pages size is 1MB or more while the text is usually 1-2Kb. That means we have roughly 1000x spent on styling/layout in relation to content. I wrote a post about this back in 2006, still true. https://gregraiz.com/graiz/2006/09/25/ten-reasons-why-css-su...

[DiggyJohnson]

I’m not sure I agree or at least understand how a page could be sending 1000x more styling data than the raw HTML without a heavy un-optimized framework or heavy JS injection.

[MrJohz]

That post feels... very 2006, and it may be worth revisiting CSS with fresher eyes, because almost none of that seems to true to me any more.

Cross-browser compatibility is very rarely an issue that I actually run into any more; flexbox and CSS grid have solved a lot of your concerns about layout options; there aren't a lot of areas of duplicate functionality (especially in rounded corners); CSS is declarative (I just didn't get this point at all - parsing CSS is rarely the bottleneck in modern browsers); and CSS is a lot easier to use than it used to be.

I think the most important point is that the comparisons with things like Word or PDFs miss the most important thing that CSS/web design needs to do, which is work for any browser size on any device in a huge variety of contexts. A PDF is, as you say, design-centric in that I draw a design on a screen and that design, exactly, is reproduced in the file and therefore on someone else's screen.

But the tradeoff made there is that the PDF file they open will be the exact size and shape that I've chosen. With websites that's just not possible. You might be on mobile, you might be on a desktop with an extra-large screen, you might be on desktop but with the browser window snapped to the side so you can view something else on the other side of the screen, or you might just be using a particularly unusual monitor with odd proportions. The promise of CSS is that my design will still fit your browser window well, even as you resize it.

This means that rather than say where I want my image to be, I need to say how I want it to fit on a generalised screen. Or rather than define N columns, I need to define a grid with automatic columns of a certain width. This, it turns out, is very hard to encode in existing PDF-/print-oriented software where all sizes can be hardcoded.

I'm very unconvinced by your idea that there is 1000× more CSS to can content. In my experience, the single largest contributor to web bloat is tracking scripts, followed by other forms of JS, followed by images. CSS is very rarely so big an issue unless you're pulling in an entire CSS framework.

[DemocracyFTW2]

> the PDF file they open will be the exact size and shape that I've chosen. With websites that's just not possible

to be fair, that's exactly what I get to see on a lot of websites in the rare event that I open a website on my mobile phone at all.

[bobthepanda]

i mean it kind of depends on what of the new stuff you actually want to use.

as a general example aspect-ratio is a neat property but was only introduced in safari 15. there's still a bunch of people using versions of safari older than that. :has came out around the same time.

[000ooo000]

>still true

Uh.. doesn't sound like it

[DemocracyFTW2]

> web-pages size is 1MB or more while the text is usually 1-2Kb. That means we have roughly 1000x spent on styling/layout in relation to content

only assuming that images do not take up the bulk of that MB, and / or belong to the 'styling' category, not the 'content' (as the case may be)

[xigoi]

If a page has 1MB of CSS, it's from bloated frameworks. But are you sure it's not the JavaScript?