Have you ever worried that you’re approaching CSS all wrong? That you’re missing out on some new approach that makes everything easier and better? That you wish you were more confident about the state of your CSS?
I’m sure we can all empathize with Anna’s sentiment here:
My CSS is full of self-doubt. What class name system is best practice today, and is the cascade good or evil this week?
— Anna Debenham (@anna_debenham) November 13, 2014
I worry about you if you work with CSS a lot and have never felt that. You’re either scary smart or, you know.
Here’s how I’m trying to approach CSS these days: just try and do a good job. I don’t subscribe to any specific methodologies or strict rules. More like a set of loose guidelines that attempt to keep things under control, held together by the idea that I’m actively trying to do a good job.
Caveat: this is just me. I mostly work on projects where it’s mostly me touching the CSS. That applies also to 55% of you, accordinging the most recent poll running here. I’d speculate that the more people you work with, the more benefit you get to stricter rules than I adhere to.
Here’s a little elaboration on “just try and do a good job”:
Don’t be lazy. You know when you’re being lazy about something. By which I mean you slapping in a quick fix for something rather than trying to understand the problem. Or dropping some CSS into whatever file seems convenient at the moment rather than thinking about where it best belongs. Or you are avoiding creating a new pattern when it seems clear that’s what the situation calls for. Or continuing to use a pattern that is biting you. Sleep on it. Don’t rush. Do it up right.
Do things how you would do them. You know what? I like light usage of child selectors in modules.
.module > h2 clicks with me a lot of times. Certain strict methodologies would disagree. I don’t really care. I’m going to keep doing it until it actually causes some negative consequence, which it hasn’t yet. If it does, I’ll change, because see above.
Name things how you would name them. If I let a methodology tell me how to name things, I know me, my mind starts staging a coup. I might play along for a day or two until I abort the methodology and take full control again. On projects entirely build from my WWINTT (What Would I Name This Thing?) strategy, I feel most comfortable and efficient.
Use tools that are clearly useful to you. I’m not even going to name any tools because that’s not what this is about. If I can identify a tool that has clear benefits to me, I’ll use it. It could save time, produce better output, allow for better organization, solve a performance issue, automate a best practice, whatever. I’m in.
The one “rule”ish thing thing I really believe in: keep your selector specificities fairly low and flat across your whole project. Harry’s specificity graph is a nice way to think about this. Specificity will trend upward, so never start high, as the ceiling can easily become problematic. Mostly:
Revisit sections of your site on purpose. Probably not just because you want to clean up the CSS there, but because you want to make that section of your site better in some way, for everyone. I find that every time I revisit an area, it’s an opportunity to clean up all the code that touches it. That helps me feel connected to and less afraid of old code.
I think it’s easy to feel this way about all manner of web technologies, not just CSS. I also have these debates with myself constantly when it comes to HTML, PHP, jQuery, etc. In some way it’s a healthy way to think, because it means you accept that you aren’t perfect and you can always learn to do better. You can also rejoice in the knowledge that there is almost certainly someone out there doing a worse job than you are!
On the other hand it can drive you nuts, often because you’re trying to perfect a technology that is imperfect in the first place.
I think the other thing that’s important is that you remain consistent. If you do things a particular way, try to stick with that convention throughout and not chop and change.
This is the most sane article I’ve ever read.
Chris, awesome article. It’s this kind of down-to-earth, sensible, applicable advice that keeps me coming back to your site everyday. This one is especially helpful for me because I frequently get lost in how I “should” be doing something, and I forget to ask myself if it actually makes sense for me to be doing it.
I needed this right now, and not just for CSS. I’m trying to package a site for production, and for every choice I made, I found myself going online to find out if I did it ‘the recommended way’, how other people did it, what people named what, doubting myself mercilessly and driving myself crazy changing things around over and over when they already fine. It’s a terrible cycle. I’m trying to go more with my gut.
Great points all around. Though I want to say for “Name things how you want to name them”, I think this approach will only work in the most ideal conditions, with one person primarily in charge of the creation of new module and elements.
As soon as I needed to coordinate name creation with multiple people, it seemed immediately clear that I needed to implement some sort of system, be it BEM or whatever. I might be the only one touching my CSS, but I’m not the designer — who is ultimately in charge of what each piece does and often what it gets named.
On a large project going through multiple stages of design revisions, it became such a problem that I don’t think I’d approach a new project again without at least setting up some loose guidelines first.
This is particularly interesting as one could think that, as a css guru, you would be an advocate of conventions. I hope it’ll help people to relax about those new approaches and open their mind.
Well, he mostly works alone on the CSS parts, so he can afford this. Most of us work in teams, where strict rules are a must. We can’t afford to be as relaxed.
I agree with you. However I don’t think that the point is to avoid conventions but rather to stay open-minded. You shouldn’t forbid yourself to use child selectors just because you read it’s bad practice or it’s not BEM-like.
Great post. I’ve been starting to believe this myself.. after each project I look back over the code and kick myself for not implementing this new technique or following that new ‘rule’.
I think if we all keep up to date on trends, and do our best to keep our code clean & modular, you’re already winning the uphill battle.
Hey Chris, under the section “Do things how you would do them.” you have a typo here “I’m don’t really care” . Great article and I subscribe to the same feelings in writing my css
Thanks! Just fixed that typo. Glad you enjoyed Chris’ article =)
Is it a good practice for freelance developer? For the closed projects? When you don’t want someone just easy copy>paste of your hard work?
Don’t get me wrong, I’m not against Anna’s point of view, just can’t decide what’s more important… While I come back to my code, it’s not so fast to get remember what was some class for, finally I find it – but starting to think that it’s a big waste of my time. Any pros or cons of my point of view in your opinion? I know there’s a lot of developers who think similar to this.
Great article, thank you for writing it. I’m more than guilty of debating methodologies for hours in a 1 man setting.
Thanks, Chris. Articles like these are like a breath of fresh air. Sometimes we need to be told to just chill out. I often forget that there’s no ‘Code Police’ to arrest me if I mess up or if I do something differently than someone else.
Thanks for this wonderful article, gets be back on track :)
Good article. It makes total sense when you work on your own…
Thank you for posting this article. There are so many new techniques out there seemingly every day that it’s hard to know what’s “best”…this is great advice.
Thanks Chris for this interesting article.
The same way as mine. My rules are all about maintainability. Nothing bothers me more than old code written in some trendy style which I’ve forgotten about. KISS
For me learn SASS helped me a lot to dull most of the problems mentioned in the tweet. Once you feel comfort with CSS the next natural thing is include a pre-processor in the workflow. So far it has worked for me.
well chris somehow you are right in that sense. But Why we do css if we have to a good job ;) hope you got it
A good article, using a methodology helps making bigger and scalable systems, but sometimes it just get’s in the way of solving a problem. When producing something more complex I always go with the somewhat loose BEM and use Sass for handling the CSS. When creating a simple 404 page or a simple one pager I use regular nesting, element selectors and similar, no need for structuring simple things when they can be easily rewritten at any time of their lifecycle. When working in teams there should be certain rules and good practices.
Then for all that is holy, don’t read Adaptive Web Design – I’m only on Chapter 2 and we haven’t left HTML yet. Learning so many markup elements I never understood before. It’s like a huge, compact dose of “you’re doing it wrong.” I think it is healthy, and I won’t incorporate everything in this book, but it’s humbling to know how much I just skipped over in the past.
Chapter 3 is CSS, and I’m nervous…
Nothing worse than going back to a site that you did 2 or 3 years ago and saying “what the hell was I thinking?”
I just go by “does it validate?” and live that way.
Child selectors make sense when they make sense (this goes back to the ubiquitous “it depends” rule). Do you want to select the H2’s that are in the elements with a class of “module” because they are in the elements with a class of “module”? Then use
.module > h2. That tactic actually does make sense. The rules of CSS make sense but it doesn’t mean they all need to be used all the time, but that doesn’t mean some rules should never be used just because a certain person doesn’t see a good reason for them.
CSS is one thing I am not good at. I am currently on my learning process and I will definitely consider your tips. I’m glad I found it before I start a project. Thanks for sharing.