CSS Guidelines You Don't Hear Often Enough

1. You should never use ID selectors, only classes.

There is a rare exception to this, but first let me illustrate the point.

The obvious problem with using ID’s as CSS selectors is that an ID only appears once in valid HTML markup. This means that you can't reuse those styles on other elements. Our goal should be to share styles between elements whose appearances are related. If we can only use the styles assigned to that selector once, we preclude ourselves from doing this.

But that can be a fairly unconvincing argument in specific cases. There are often times that you can be almost certain you’ll only be using styles once (e.g. for a website’s main navigation).

The more important point is that it ID’s mangle the specificity of your selectors.

Let’s give a quick example.

<!doctype html>
      #site-header a {
        color: red;

      .main-container .site-link {
        color: blue;
    <div class="main-container">
      <header id="site-header">
        <a href="#">Link 1</a>
        <a href="#">Link 2</a>
        <a href="#" class="site-link">Common Link</a>

        <a href="#" class="site-link">Link to somewhere</a>

    <footer id="site-footer">
      <a href="#">Link 1</a>
      <a href="#">Link 2</a>

In this case, even though our intention is to make all .site-link's blue regardless of where on the page they fall, the .site-link's in the header and footer will be red, because the #site-header a is more specific. We'd have to change the .main-container .site-link selector to .main-container .site-link, #site-header .site-link.

This seems ugly, but possibly trivial in this example. But when you have a full-scale website or web app, this grows out of control very quickly. The next thing you know you have !important everywhere to override these selectors, and you've fallen into a trap of over-specificity.


If you are creating a snippet of code that is to be inserted (embedded) into an arbitrary HTML document, you should give a container around the snippet an ID, and prefix all CSS selectors with that ID. This ensure that your styles will override the default styles of the document it's being placed into, while simultaneously guaranteeing you won't be restyling existing elements in the document.

2. Be meticulous about formatting

That's indentation, spacing, and naming conventions. And keep your lines as short as possible. Scrolling horizontally and/or wrapping text are impossible to read.

3. Don’t style base elements

Don’t style all h1’s, or all header's. Instead style a class, or all h1’s within a particular class. If you don't do this, you're going to be constantly fighting styles you've creating in all sorts of different contexts. The code becomes much larger and harder to understand.


.page-title {
	/* something */

.site-header h1 {
	/* something */


h1 {
	/* something */

4. Don’t separate your CSS out by pages

Start by looking through every page of a design before you start and pick out common elements and styles. For example, in some given design the "Login" and "New Order" form styles may be almost identical. Make sure these forms share CSS classes! There are also common items between the lists of info. You want to repeat your styles as little as possible.

When you create new CSS classes or files per page, you are precluding yourself from sharing common styles between similar elements on those pages. So now when you want to change the color of a type of button that appears all across the site, you need to hunt around for all of the places you used those same styles, invariably missing some occasionally.

5. Don’t make your selectors too specific, either.

When you’re doing things like .class1 .class2 h1 .class3, it’s probably unnecessary. Think about it in terms of the classes having semantic meaning. Sometimes it helps to think about it in English. Are you really trying to say that "only the class3’s within h1’s within class2’s within class1’s" should be styled this way? Or is it actually true that any class3 within a class2 should look a certain way? If so, then use .class2 .class3.

6. Your templates should look correct at every screen size and on all supported devices.

This seems obvious, but it's a very common oversight. Test on all targeted browsers and devices. Take your browser window and slowly resize it from mobile all the way to full screen. If it breaks at certain resolutions, you need to fix your work.

7. Your templates should hold their form as content changes

Is your layout going to break if a navigation item is added or removed? What if a slightly different size image is placed in that spot? If you add an extra paragraph of text somewhere, does everything still look the same?

The main way to accomplish this is to allow most of your elements to flow naturally within the document, utilizing containers to hold repeated or grouped elements in place. For example, avoid position: absolute if you don’t need to use it. And don’t float things when you can use display: inline-block.

8. Use two classes. A lot

Let’s say you have two arrow, a left arrow and a right one. Give the left arrow class="arrow left-arrow" and the right arrow class="arrow right-arrow". Now you can add the styles that are common to both to the CSS selector .arrow while you use .left-arrow and .right-arrow for the styles specific to each of those.

Maybe you have two forms you are working on that share the style of their inputs, but are positioned slightly differently on two separate pages. Hello, .action-form.contact-form and .action-form.job-form.

9. DON'T name ANYTHING after the project you're working on

Let's say you're developing a website for a company called ACME industries. In so many cases, you'll see developers call their CSS file acme.css, and their classnames will be acme-header, acme-this, acme-that, and acme-the-other-thing. Seems like a great idea, right?

No, it's not. I've built at least three websites for organizations that changed their name. Or maybe you built a website for a client who now wants an almost identical design for a related website? In either case, none of these names will make sense.

10. Use semantic classnames

Don't make classes called red-title and left-nav. Just don't do it.

What happens when you change your red-title to blue? Doesn't make sense anymore.

Or if you need a new page with a left-nav that happens to go on the right side of the page? That doesn't make sense anymore, either.

Call things what they ARE. page-title, main-nav, secondary-nav, main-header, etc.

Grid Image