I’ve been writing CSS for a long time. I’ve gone through many revisions of how I write it. It’s interesting how it has evolved over time.
THEN…
Like not using underscores in class names because they caused issues in some browsers (I can’t remember the particulars, that was awhile ago).
Like putting all properties on one line with tight spacing. This had the dual effect of being able to see more related classes without scrolling and keeping the file size down. (Now with preprocessors that can minimize your files this is a non-issue.)
This:
.title{margin:0;padding:0;font-size:24px;}
Instead of this:
.title {
margin: 0;
padding: 0;
font-size: 24px;
}
I know, most people hate the tight one. But you got used to it, really. I did it that way for years.
Like using ids instead of classes for layout elements (e.g. #banner instead of .banner) until I learned that that the developers at my company needed to use ids for javascript handles. Ids also make the css have higher specificity. So now I use classes for most styling.
Like using object-oriented css (OOCSS) and making use of inheritance.
Like taking advantage of existing elements instead of classing everything.
Like writing a lot of reset styles.
Like nesting a lot of LESS styles to see the structure of a component.
UNTIL…
I saw unintended consequences of some of the choices I made.
A guy named Matt showed up at my company and started questioning some of my ways. (This was a good thing. Hi Matt.)
I found SMACSS. Or maybe Matt did. Not sure, we read a lot of the same stuff.
And this style guide.
And it was funny, reading these, that their styles have also evolved, and that some of what they do I do, too.
NOW…
Here’s where I am with my CSS. Which is some of what I have learned along the way, some new stuff, and some still-to-be-determined-if-it-sticks stuff.
I write minimal reset styles. I found that aggressive reset styles force you to write more overrides. And there was one issue with Internet Explorer where if you set a property, it could never be set back to auto. I can’t remember which property that was, sorry, it’s been awhile. But I’m guessing it was an issue with buggy IE 7.
I format CSS the way the rest of the world does. But I group my properties in a certain order, which makes it easier to find them when there is a big block of them. Like box model styles first, then visual styles, then fonts, etc. If I weren’t working with other people, I’d most likely also lump some of them on the same line, like so:
.box{
position: absolute;
top: 0; left: 0;
width: 100px; height: 100px;
border: 1px solid #eee;
font-size: 12px;
}
I use more classes. I got in trouble with OOCSS and using elements instead of classes. So now I follow the SMACSS guidelines of creating a component where the name of the component is in the child styles. At least for the main child components. This also allows me to flatten my CSS. And it’s the opposite of where I was, trying not to class everything. I’m not sure where I’ll ultimately land but, for now, I’m leaning towards adding classes. It seems to be more future-proof.
So now I’m doing this:
.section { … }
.section-header { … }
.section-body { … }
instead of:
.section { … }
.section h1 { … }
.section div { … }
Yeah, you can already see the issues, right? .section div { … } is not smart. I wasn’t usually that generic, but for a small component where I thought there would only be one div or span or link or image, I fell into this trap. And usually got burned.
I use the is- prefix for state changes, like .is-hidden, .is-selected, etc. And ids are only in the html, for javascript / aria purposes.
I use a namespace for styles I create, so they don’t clash with any css I bring in externally. Like gert-btn, gert-heading, etc.
I’m trying the SMACSS l- prefix for layout classes. The thing is, I feel like sometimes the layout / component dividing line is gray, and I’m not sure I want to take the time deciding which bucket to put something in and then wishing I hadn’t. So this one is kind-of experimental at this point.
I comment, comment, comment. That’s one thing that’s never changed, since I was a young whipper snapper cranking out code. Only now I mix /* */ comments with // comments. The latter are used in LESS and SASS and don’t get written out to the final CSS file. Sometimes I want a comment to wind up in the CSS, but usually the disappearing comment is good enough. It just tells someone else – or reminds me – why I did something the way I did. I also like using them at the end of code blocks, in case indenting gets messed up. I really hate spending time finding matching braces. I do this same code block commenting with html comments.
Also, with preprocessors, I’m starting to put media queries right near where the adjustments need to be made.
And I’m using variables for colors, typography, and oft-reused styles, like standard padding. But I’ve seen this overdone, too, with variables for everything you might possibly want to change and variables using other variables. It can make things way more convoluted than they should be. But variables are great for theming!
Lastly, instead of integrating hacks – because there aren’t many needed anymore – I’m starting to use a hacks.css file. Or, as some like to call it, a shame.css file. Its for things you put in place in a hurry that you know can be done a better way but you just haven’t figured it out yet.
You know of what I speak.
So, do you think about your CSS? Or do you just write it any old way? I feel like having a system makes coding simpler and faster and easier to maintain.
Only don’t get set in your ways! Because there are always things that work and things that don’t. And things that change over time with browser and CSS capabilities.
Now go get stylin’!
You’ve got to try your own thing, I know, but it’s still worth listening to your elders and learning from their experience of what works and what doesn’t. And elders can also learn from the youngsters and their new ways of doing things. People who are open to learning and sharing make better coders. They make better everythings, really.
Hugs.
