https://www.w3.org/Style/CSS/specs.en.html
You can read this and know most things about CSS. For a bit anyway. You'll forget things you don't use. You might remember them again one day.
The primary purpose of frameworks was to work around the quirks in all the different web browsers out there, and to implement grid-like layouts before we had css grid, and to deal with the impossibility of centering a div natively. None of that is necessary these days, and hasn't been for a decade.
I've always now-and-then packaged up and open-sourced the pattern I use for CSS. The projects have gotten smaller and smaller. This reflects well on CSS as a technology.
I think class="" has more to offer in an information density sense. There's more potential there than style="" had. Instantly lumping them together was my first response too, but I was wrong. The in-the-HTML shorthand of frameworks like Bootstrap/Tailwind/CASS is insanely useful in a way that inline styles never were.
https://en.wikipedia.org/wiki/Pattern_matching
Also:
https://en.wikipedia.org/wiki/Pattern_recognition
And (early 2000s skeptics idea of the term, a useful abstraction):
https://www.youtube.com/watch?v=1AjLmU0Sfu4
Sometimes people call it:
https://en.wikipedia.org/wiki/Cargo_cult_programming
All just to say, w.r.t. CSS, if you are doing this, you don't really understand what you are doing, why browsers added a feature, what the language is, you are just replicating patterns because you saw other people do it.
You were assimilated into behaving a certain way, and you continue to look at the patterns your org or community follow and you just are a victim of the https://en.wikipedia.org/wiki/Bandwagon_effect or you never had time to learn and you are a https://en.wikipedia.org/wiki/Script_kiddie or https://en.wikipedia.org/wiki/Lamer (or what people used to refer to as hackers outside of IT).
You know you can do it, but you don't know how it works, why it matters, or why you should care.
Meanwhile, you can learn about these patterns, study them, comment on why people use them, critique their flaws, benefits, etc.
Those people used to be called a https://en.wikipedia.org/wiki/Software_architect or one who studied https://en.wikipedia.org/wiki/Sociology
Still, a part of me wonders how different my life would be if I had taken to frontend programming enough to make things that look nice. It's not like there isn't anything enjoyable about it, I just ended up taking to backend distributed systems work a bit sooner.
The book has a lot of content over what to make pretty and what not to make pretty. I think knowing what not to bother with is an underrated skill. A lot of what inspired me to write it was backenders handing off markup that they tried to make semi-passable. Unstyled HTML, please!
Big problem with evergreen standards: if you try to come back to a standard that is now twice as big but still has the same version number, there is nobody writing books to teach you what you missed out on. Want to come from CSS2 to 3? They got you. Want to do backend development for five years and then get a summary on what you missed? Go fuck yourself.
I'm not saying that this is a "bad" thing, but the last time I did any significant amount of frontend stuff was back in ~2014, and it was AngularJS, which was considered pretty ok at the time I think. I left that job and started doing almost exclusively backend stuff for several years, and when I looked back, the entire world had switched to React and transpiling JSX and a lot more CSS than I was familiar with.
It seemed pretty intimidating to try and pick that up again, so I never really left the backend stuff, and now I've managed to even avoid web stuff for awhile, because I kind of hate web programming.
Almost 100% in lighthouse for both mobile and desktop, responsive, reusable components, dark/light mode and a design that was better than I could do in the 2-3 hours I spent doing it (while sipping wine).
I know its not a solution for everyone, and probably won't work for the prettier designs out there, but you can go a long way with these tools this day.
I know there is a reluctance to not use LLM's for code tasks, and I am one of the largest critics, but for me this solves a real pain point. I don't want to write CSS/HTML anymore and these tools do a good enough job of it that I don't have to.
I actually would be happy to just "vibe" code my way through most of the problems I deal with if LLM's were able to do it.
That said, they make a great intern or jnr developer you can hand tasks off. You have to review either way, but the LLM does it faster.
Now that CSS is more or less feature complete and the fact that there's just one web browser means you don't need the clever tricks rolled up in a framework to center a div or to have a grid layout that works without resorting to tables. It's literally part of the CSS spec and has been implemented in every browser for a decade now.
I mothballed this project because people were so incredibly cruel about it (a CSS project!). Remember that people who work on this stuff are people, and we're just trying to make things better. Also, you can pry .vertical-center from my cold, dead hands.
.center { display: flex; justify-content: center; flex-direction: column; text-align:center}
.vcenter { display: flex; justify-content: center; flex-direction: column; }
.hcenter { text-align: center; }I agree. Also users/product managers do not care. They will see UI that is a little bit “off” and think negatively about your brand. Congrats, now you have a ticket to make the UI look pixel perfect.
I suppose the audience for this isn’t people who actually get paid to write CSS, but instead casual blog writers. It’s definitely ok and normal to have little blips on your side project.
It's basically "the arbitrary padding the designer liked in the moment" vs. "the standard padding that's everywhere in the project." This book argues you should always use the standard padding. Your product should be pixel-perfect, just not in the PSD-to-HTML sense.
Oh yeah - I remember my first job things had to be pixel perfect to what the boss had mocked up in Photoshop. Thankfully at my next job it was just use whatever the project's CSS gives you unless it looks terrible.
I don't do much frontend any more but my current marketing team is happy with anything that looks reasonable.
Like QA not passing some detail because they think it should be different. Where in reality it is what it is because of framework etc.
Yes you mostly can do everything - but not everything is worth spending time/money on.
CSS styling used to take me forever, now I basically just tell AI the contours of what I want, and it gives me the vast majority of what I want. It often has some bugs, and I always need to edit/tweak it to get things right, but it probably saves me 90% of the time I used to waste on CSS (I'm primarily a backend dev).
You've turned your/rriepe's substack series (https://news.ycombinator.com/from?site=yousuckatcss.substack...) into a book? Or actually maybe it's the other way around (based on rriepe's profile[0])
The book morphed into being more about project management. I think there's a lot of value in it still, in that respect, so I'm putting it all online for free.
With modern features like CSS nesting, anyway; just a few years ago when IE support and whatnot was more relevant it was a different story. Now you can just throw everything into a flexbox.
.every-stupid-ass__naming-scheme-falls-short{}
Things like BEM give you the most flexibility for extension, things like atomic CSS (tailwind) give you the most velocity for not giving a fuck about ever touching the markup again.
This is a #wontfix (sorry), but I might fork it into a new, LLM-oriented CSS project. Fonts and lists will be the first things I look at.
A long time ago, everyone in my team kept making excuses why they hate css. I went to Lynda.com and found a pretty good class. I can't remember the instructor, but it was so good that I still use the same patterns more than a decade later. I tried to get the whole team to take it, but no one wanted to. "It's a waste of time", "It's not even a programming language."
They built all kinds of tooling around css, trying to avoid css. We had dormant css that no one could ever figure out if it was used, we had important and position absolute everywhere. Today, it's not so different. You see divs with 20 or 30 classes in them.
Just learn css. Any class is better than no class.
- Regex
- SQL (if you do some backend work)
- CSS (if you do some frontend work)
- Bash + basic CLI tools (vim, grep, find, sed, awk)
- Git
Really learning these makes your life sooo much easier.
Isn’t that exactly how you’re supposed to use tailwind?
I would not advocate constraint solvers, in the future I hope ViTs are so cheap to run that they can infer the right layout of things at any orientation and size in single digit milliseconds, solving the layout problem for good =)
The reason CSS is hard is the same reason that SQL is hard for some.
But I like SQL so I kinda like CSS.
Why? Because it has syntax you despise or what? The syntax (nor semantics of said syntax) is nothing like SQL.
I feel like people who say things like this are just trying to say anything, and it is meaningless. Do you have a take on that?