DEV Community

Gladdstone
Gladdstone

Posted on • Updated on

Styling Your Stylesheets

CSS. Cascading Style Sheets. We know them, we use them, we - well, "love" might be a strong word, but we certainly use them. Whether you're a Bootstrap evangelist, or a do-it-yourself purist, if you've ever designed a website, you've at some point had to write some CSS. This means that at some point you've had to read some CSS, and perhaps even modify someone else's. In that case, you know the pain of finding exactly the tag you're looking for.

So what is it about CSS that causes such animosity, or at best, reluctance? It's a perfectly simple technology, utterly usable in nearly every aspect, dead simple to learn, and even if you absolutely refuse to write it, there are literally thousands of tool/frameworks out there that exist solely to ensure that you never have to. So why expend the energy required to hate it?

Okay, so you might be on to something there. CSS has it's problems, but its biggest problem is really the user (which, if we're being honest, is the case with a lot of things we hate).

CSS's greatest enemy is organization. Often times, people will do a reasonable job of organizing their CSS at first, but after two, three, four updates, it's not looking so hot anymore. As a student, I've had the pleasure of working with a number of wonderful people on everything from freelance, to group projects, to internships, and everything in-between, but I swear if one more person inserts their random-ass ID selector in the dead center of my code I am going to lose it.

As something of a professional whackjob, I'm pretty scrupulous about formatting my code - not necessarily by standard convention, but by what I find to be most readable. Sometimes this means adhering to the styling conventions of the language, and sometimes this means improvising slightly. Often, this improvisational style of coding leads to some discrepancies from program to program, or site to site, so this is me, sitting down, and attempting to set in stone at least a few of the rules I attempt to follow on a daily basis.

1. Order Your Selectors

CSS has three main selectors, and of course, a near infinite number of combinations and permutations thereupon, so I try to keep it reasonably simple. First and foremost, I always start my CSS in the same way, with the universal selector (*). Being universal to every element on the page, this seems fairly logical.

Next, you've got your standard HTML selectors. The reasoning for this is that, overall, HTML selectors are the most broad in scope (with the exception of the universal selector), as they effect every element of that type. By putting them first, you ensure that ID and class selectors will properly override their respective elements.

Following the HTML selectors is ID, if for no other reason than that's the way I chose to do it, and bringing up the rear is class selectors. If I were following my logical reasoning from the previous paragraph, I suppose it would make more sense to have class followed by ID, but I'm a fairly stubborn person and it's unlikely that I'll change any time soon

2. Alphabetical is King

So you've got your selector in order. That's a good start. You know where your IDs are, your HTML element selectors, your classes, each one of them has it's place. That's probably good.

Now, just need to change the width on #profile from 75% to 70% and...

You see where I'm going with this. Once I have my selectors in order I further break it down alphabetically. #that_div, #this_div, #those_div, you get the picture, it's not rocket science. The part where it starts to break down is when you get into subselectors, such as when you're pointing to children, or adding a hover.

As a general rule of thumb, if two selectors start with the same word, the longer one goes second. That is to say ".link:hover" comes after ".link".

3. Breaking All The Rules?

Due to the nature of CSS, it's not always possible to follow all of these rules to the t, and that's okay. I know I very rarely write any CSS in which I follow every one of these rules perfectly, simply because CSS wasn't written to operate in this way.

Very frequently, you'll find yourself in a situation where element A must come after element B in order to display properly, and I tend to doubt anyone is changing their entire design for the sake of better organizing their CSS (but then again, who am I to judge).

This isn't necessarily a complete ruleset, and it's certainly far from perfect, but I do believe that by following a few extra rules of thumb could help prevent some headaches for both you and your coworkers in the future.

Thank you!
Thanks for reading my first ever attempt at a tech blog! Feedback is certainly appreciated, my writing ability is a permanent work in progress.
You can follow me on Twitter @Pithpifth

Top comments (1)

Collapse
 
rhymes profile image
rhymes

Welcome!

Organising any type of code can become tedious, I tend to configure tools to help me to do it. In the case of CSS in a project I used successfully stylelint.io/ - you can configure it as you like.

There's also a set of rules for SASS/SCSS if you use that: github.com/bjankord/stylelint-conf...

Hopefully it might help with organisation :-)