You can prove that most people don't learn CSS using most LLMs: they're trained on github code.
A card with a top image, some text and a button - which should be...
- A card
- A top image
- Some text
- A button
ie 4 HTML elements, ends up being about 10 HTML elements with various strange hacks in the div-soup HTML the models have scraped from Github.
Then someone else comes along and uses tailwind, because naming 10 arbitrary HTML elements (rather than .card, .card img, .card p, .card button or similar) is hard. They're right, but the problem is they didn't need that many elements in the first place and wouldn't if they'd just learnt CSS.
CSS has gotten much, much better, which is why it doesn't suck so much these days, but come on now, using a div with a background image was a common practice. There were like, what, 3 different hacks to center an element inside another?
People don't just opt for a plethora of different tools to deal with it "just because".
Well first of all CSS is complicated. Second, it changes constantly. Third, there are no widely-used conventions and best practices.
You are either a full-time front-end dev and have a chance to keep on top of it, or you do not know CSS, and are now blamed for it sucking.
To garner that, many people just want a simple UI that is not ugly -- not everyone wants a web design masterpiece, thus they 'don't bother learning it'.
I know CSS and believe me it sucks. Sure grid layout and flexbox fix things. But a lot of it is hacks on top of hacks.
Why do you think the padding as a percentage is relative to the width of the parent? Do you think it was a happy accident? I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg.
The good thing is that all the hacks together make a working thing. And if you know them you can do a lot of stuff.
That is my impression too. From my experience, the fact that I used it early on makes me use it in the "wrong" way as the fundamental concepts have changed a few times.
> "I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg."
I don't think that css evolved with specs, the HTML/CSS specs were descriptive rather than normative, and they came after the browser wars and the organic clusterfuck.
I know CSS, but also a few other displays and layout engines.
In my experience "CSS sucks" right up until you try to do a tenth of what it offers in something else. Cross-platform, device-neutral UI is hard. Then allow user-provided alterations?
> Why do you think the padding as a percentage is relative to the width of the parent? Do you think it was a happy accident? I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg.
It’s because you cannot do a percentage of a height unless your parent’s height is fixed - something that happens naturally maybe 1% of the time. You’d be missing vertical borders in almost every case with your suggestion
I've spent a LOT of time trying to learn it. I've read the O'Reilly book, CSS zen garden, Eric Meyer on CSS, and the spec itself... I still think it sucks.
It's also just kinda bad. Like, people were celebrating the has() pseudo class allowing them to do things with selectors that would be trivial in XPath in its first version 20 years previously.
I will give the people who work on CSS props though, they are the only ones interested in advancing browser's capabilities as something more than just a JS runtime, that is to be commended.
I imagine it's a difficult language to ride the saddle-point of capability and performance. A declarative language like that seems like it'd be easy to design a feature that, as a side-effect of existing at all, slows rendering globally by 5%.
It's partly a case of people mean different things when they talk about "a grid" and how they would use a grid. Bootstrap popularized one simplified model of layout they called "Grid", and MUI is continuing a version of that. CSS Grid is an attempt to unify that simpler "Grid" with more powerful grid constructs and as a more generalized 2D layout engine. It takes the things learned from Flexbox and Table layout and tries to unify them into a sane 2D layout system that has the power of both and additional tools.
I think you can replace nearly every use of Flexbox (and Tables for layout) with CSS Grid and have overall better dev ergonomics. The `grid-template-areas` tool and named areas can be great dev ergonomics far better than anything that came before it in CSS, especially if you have highly responsive layout needs and/or desire to decouple HTML source order with layout order (for better, cleaner accessibility, for one instance; or for cleaner streaming order on slow pages, as another reason).
It has a learning curve more than the simpler "Bootstrap-era" Grid designs, certainly, but I think it's an easier learning curve than Flexbox (but esp. if you've already learned Flexbox, because they share a number of concepts).
Another big problem is that designers never got the "semantic" bit. I don't know how much of that is that most designers aren't used to thinking systematically and like to design a page at a time instead of a system for a whole site and how much of it is CSS being structurally wrong. So we have MUI and bootstrap to impose an application-like structure or tailwind to just "do what I mean".
In the example there is a mixture of style and content. This would be of course more ergonomic. However, the strength of CSS is that you can decide later on to change the style without touching the content.
"There are people who care about the UI. I can’t do UI to save my life. I mean, if I was stranded on an island and the only way to get off that island was to make a pretty UI, I’d die there."
Back in the "golden age" of Web my development career, circa 2008, before "full-stack" and before SPAs, we were fortunate to have people that specialized in UX and CSS. They understood fonts, colors, spacing, browser quirks, and they understood CSS. They have their own conferences and bloggers that they followed. (Eric Meyer) They were technical enough to deal with a Git repo and commit css and image files. The back-end / "CS major" types could simply focus on the CRUD part of the application and didn't have to care about UI or CSS.
1) Why is it using an NIH format instead of using XML or INI or something?
2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently.
3) It's too global. This is good for consistent styling but bad for modularity.
4) It's too much of a moving target. Best practice for html+css+js changes constantly.
5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test.
6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.
1) doesn't seem to be a very big issue, the syntax is quite simple and readable. Arguably, INI or XML would have been worse. INI especially would have been a shame, now that we can nest blocks. XPATH selectors would have been nice, they are more powerful and barely less readable.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
> Why is it using an NIH format instead of using XML or INI or something?
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
Anyone that actually works with CSS will tell you it is the platform specific standards mess that made it a problem. Try something fancy, and it will likely become a bug later.
It gets painfully clear if you want pixel-perfect layout on every desktop screen, mobile screen, and browser. YMMV, and PDFs will be around forever now... =3
The only part of this article that I disagree with is "It's much easier than your traditional programming language" because it very much isn't. I don't program in many languages, but I can read most that I come across and mostly understand what they're doing. CSS to me seems like a pile of rules, rather than something with control flow.
If you want to learn CSS, and I mean, REALLY learn it, buy "CSS: The Definitive Guide" (https://www.amazon.com/CSS-Definitive-Guide-Layout-Presentat...), read it cover to cover, and use every property in playground while you're going through it. I was a backend developer that hated CSS before it, now I love it.
CSS also sucks because 10px isn't 10 pixels, 10cm isn't 10 centimeters, and 50% isn't 50% of the screen.
But yeah, many people learn the intended syntax, but don't learn the actual clusterfuck of its backwards compatible standardless behaviour. I'm convinced you can do almost anything with just html,css and maaybe a tad of vanilla js.
CSS is tricky, touch one place the whole thing could collapse. I guess that just the nature.
I find this course is very helpful for me https://css-for-js.dev/
I've tried picking up CSS several times but always revert to plain text or some simple rectangles. I just don't have the patience for mastering web design. Fortunately, AI tools are now capable enough to handle the heavy lifting, allowing those of us who hate CSS to actually ship something that looks professional. :)
I had the same realization about myself some time ago: I suck at styling because I never bothered to try to learn css. I know enough by heart to solve most basic problems, but anytime I spend more than a couple of minutes on styling, I'm inevitably scrambling search engines (and these days asking llms).
The analogy with learning programming languages is helpful to get the point across but pretty inaccurate. Most of us should treat css more seriously (I for one just want to get done with it as soon as possible), but it's not realistic to compare it to programming. It's like comparing building a sandcastle with building a house.
I think it's the "cascading" part that makes it laborious.
If I have an element with a class on it, there are multiple selectors that can affect it.
It can be because it is contained within another element, because it is an element, because it has a class, because it is an element with that specific class, because it is next to an element, and many others.
I have thought CSS sucked since shortly after it came out. I tried learning it more than a few times in the last 28 years, on a couple of occasions I actually managed to do something I wanted. The reason I think it sucks is because I can never remember any of it when I need it. Contrast with html, which I first learned in 95 and have never forgot the basics of, even when going years without using it.
81 comments
[ 2.8 ms ] story [ 69.4 ms ] threadA card with a top image, some text and a button - which should be...
- A card
- A top image
- Some text
- A button
ie 4 HTML elements, ends up being about 10 HTML elements with various strange hacks in the div-soup HTML the models have scraped from Github.
Then someone else comes along and uses tailwind, because naming 10 arbitrary HTML elements (rather than .card, .card img, .card p, .card button or similar) is hard. They're right, but the problem is they didn't need that many elements in the first place and wouldn't if they'd just learnt CSS.
CSS has gotten much, much better, which is why it doesn't suck so much these days, but come on now, using a div with a background image was a common practice. There were like, what, 3 different hacks to center an element inside another?
People don't just opt for a plethora of different tools to deal with it "just because".
the "it" you have to learn has constantly been a moving target. That's its biggest problem.
You are either a full-time front-end dev and have a chance to keep on top of it, or you do not know CSS, and are now blamed for it sucking.
To garner that, many people just want a simple UI that is not ugly -- not everyone wants a web design masterpiece, thus they 'don't bother learning it'.
It's almost always an inequivocal mistake to use a feature that was released last year.
Why do you think the padding as a percentage is relative to the width of the parent? Do you think it was a happy accident? I don't think so, it was purposefully put there in the specs so that we could have boxes with fixed aspect ratios. This is just the tip of the iceberg.
The good thing is that all the hacks together make a working thing. And if you know them you can do a lot of stuff.
This is how it works for me:
https://media1.tenor.com/m/QWdPngpHxZ8AAAAd/family-guy-css.g...
I don't think that css evolved with specs, the HTML/CSS specs were descriptive rather than normative, and they came after the browser wars and the organic clusterfuck.
In my experience "CSS sucks" right up until you try to do a tenth of what it offers in something else. Cross-platform, device-neutral UI is hard. Then allow user-provided alterations?
The serious answer is:
1. Many early web engines used `display: content-box`. So the padding was actually considered to be outside of the box itself.
2. Early web engines were strict about height-can-depend-on-width, but width-cannot-depend-on-height to avoid circular dependencies.
It’s because you cannot do a percentage of a height unless your parent’s height is fixed - something that happens naturally maybe 1% of the time. You’d be missing vertical borders in almost every case with your suggestion
Which is the actual issue. Learn CSS and treat it as part of the web stack.
I will give the people who work on CSS props though, they are the only ones interested in advancing browser's capabilities as something more than just a JS runtime, that is to be commended.
Look at MDN, the gold standard for web docs, on Grid: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Grid...
That's just the basic concepts!
Now look at how easy MUI's Grid is: https://mui.com/material-ui/react-grid/
Atomics vs Usability. Everyone needs CSS. No one needs to *write* CSS.
I think you can replace nearly every use of Flexbox (and Tables for layout) with CSS Grid and have overall better dev ergonomics. The `grid-template-areas` tool and named areas can be great dev ergonomics far better than anything that came before it in CSS, especially if you have highly responsive layout needs and/or desire to decouple HTML source order with layout order (for better, cleaner accessibility, for one instance; or for cleaner streaming order on slow pages, as another reason).
It has a learning curve more than the simpler "Bootstrap-era" Grid designs, certainly, but I think it's an easier learning curve than Flexbox (but esp. if you've already learned Flexbox, because they share a number of concepts).
> It uses CSS Flexbox (rather than CSS Grid) for high flexibility.
- Linus Torvalds.
Source of the quote above -
https://youtu.be/o8NPllzkFhE?si=8vIMSR9qjVuFlvtt
If you don't want to watch the whole video, here's the exact part about the UI -
https://youtu.be/u4cI71pnFUc?si=DZqOaj6SE9yIh7Re
Transcript -
https://terence-xie.medium.com/linus-torvalds-the-mind-behin...
You can read all the programming books in the world. Actually writing a hello world program will teach you far more.
If you want to learn to play guitar, you need to start practicing simple chords long before you ever learn theory.
Not every tool out there has the same educational requirements. And there's no reason why they should.
1) Why is it using an NIH format instead of using XML or INI or something?
2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently.
3) It's too global. This is good for consistent styling but bad for modularity.
4) It's too much of a moving target. Best practice for html+css+js changes constantly.
5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test.
6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
https://www.w3.org/TR/CSS1/#pseudo-classes-and-pseudo-elemen... were in CSS 1 released as a specification in 1998. Ugly-and-weird-and-special-cased ... sure, but what would you replace them with?
It gets painfully clear if you want pixel-perfect layout on every desktop screen, mobile screen, and browser. YMMV, and PDFs will be around forever now... =3
But yeah, many people learn the intended syntax, but don't learn the actual clusterfuck of its backwards compatible standardless behaviour. I'm convinced you can do almost anything with just html,css and maaybe a tad of vanilla js.
Good luck.
The analogy with learning programming languages is helpful to get the point across but pretty inaccurate. Most of us should treat css more seriously (I for one just want to get done with it as soon as possible), but it's not realistic to compare it to programming. It's like comparing building a sandcastle with building a house.
If I have an element with a class on it, there are multiple selectors that can affect it.
It can be because it is contained within another element, because it is an element, because it has a class, because it is an element with that specific class, because it is next to an element, and many others.
And deciding which rule gets applied is work.