CODEWITHSUNDEEP
css
Art
Art

Reputation: 24577

What are the best practices for writing maintainable CSS?

I am just starting to explore this area and wonder what are the best practices when it comes to production of clean, well-structured and maintainable CSSes.

There seems to be few different approaches to structuring CSS rules.

One of the most commonly encountered ones I saw was throwing everything together in one rule, i.e. margins, borders, typefaces, backgrounds, something like this:

.my-class {
    border-top:1px solid #c9d7f1;
    font-size:1px;
    font-weight:normal;
    height:0;
    position:absolute;
    top:24px;
    width:100%;
}

Another approach I noticed employed grouping of properties, say text-related properties like font-size, typeface, emphasis etc goes into one rule, backgrounds go into other, borders/margins go into yet another one:

.my-class {
    border-top:1px solid #c9d7f1;
}

.my-class {
    font-size:1px;
    font-weight:normal;
}

.my-class {
    height:0;
    top:24px;
    width:100%;
    position:absolute;
}

I guess I am looking for a silver bullet here which I know I am not going to get, bet nevertheless - what are the best practices in this space?

Upvotes: 9

Views: 1830

Answers (9)

Alek Davis
Alek Davis

Reputation: 10732

I like Stefano Mazzocchi's suggestions in the post titled Why Programmers Suck at CSS Design. Among other things, he explains how to start from a clean slate, whether to use em or px, how to define fonts, etc. I would not use all suggestions (e.g. I would be hesitant to import any CSS -- or any other -- files from Yahoo!), but some ideas are pretty good.

And a few more suggestions: 100 Exceedingly Useful CSS Tips and Tricks

Upvotes: 1

martyfmelb
martyfmelb

Reputation: 11

If you're using class names which are likely to be used again in another context with a completely different appearance, use "namespacing" to ensure those rules don't "bleed outside" their intended context. The context is the selector for the nearest parent element inside which you will always find an element matching your un-namespaced selector.

e.g. Let's imagine you are making some styles for a reusable module, whose top level element always has the class="mymodule". All the selectors intended only for use there should then begin with ".mymodule " -- so ".item" should become ".mymodule .item", titles for your mymodule items should have the selector ".mymodule .item .title" etc.

But, don't be tempted to just replicate your entire element hierarchy exactly in CSS -- this results in very fragile , difficult-to-maintain CSS. e.g. If you think you'll be using ".product-item" outside of ".new-products", but you will want to largely preserve its appearance, you will certainly afford yourself better flexibility by not namespacing that (family of) selector(s). You can always override your styles with other selectors (of equal or higher specificity) to accommodate variations in appearance in other contexts.

Example:

.black-module {
   background: #000;
}
.product {
   color: #363; /* products look similar everywhere /
}
.black-module .product {
   color: #FCF; / products have lighter text if inside a black module /
}
   .product .title {
      color: #030; / won't affect article titles /
   }
   .black-module .product .title {
      color: #FCF; / won't affect article titles or product titles in a non-black module /
   }
   .product .subtitle {
      color: #7A7; / looks good on all known module backgrounds, even black */
   }



.article .title {
   font-weight: bold; /*won't affect product titles */
}

Upvotes: 1

Scott Willeke
Scott Willeke

Reputation: 9335

As with most "best practices" there is no right answer here. I think that others' suggestions and styles are generally good though.

While I love CSS I think CSS has failed us all in this regard. The language is stale and could use a lot of improvement in ways to help us organize large and complex CSS files. One good effort in this direction is http://LESScss.org . They have extended CSS with variables, mixins, nested rules and even operations that allow css to be a lot more DRY and manageable.

It isn't /true/ CSS as you have to preprocess the LESS to turn it into CSS that a browser would understand but that is a quick and easy step that might be worth it to you if your CSS is growing unwieldy.

So if you're finding CSS unwieldy it might be worth giving a try.

Upvotes: 0

kajo
kajo

Reputation: 5761

For me it's good to alphabetize properties of element. It is simple, visible and good for programmer's eye :)

e.g.

#my-id 
{
   color: #fff;
   float: left;
   font-weight:
   height: 200px;
   margin: 0;
   padding: 0;
   width: 150px;
}

Before production it's recommended to use some of the css compressors to provide gains in performance.

Upvotes: 0

Ken Kinder
Ken Kinder

Reputation: 13140

CSS allows you to "cascade" multiple rules against a particular element, but generally you don't have rules affecting the exact same elements right after each other. In one block, I will separate out specific kinds of directives though:

div.foo {
    float: left;
    padding: 1em;
    margin: 1em;

    background-color: #fff;
    border: solid 1px silver;

    font-family: ...
}

My thinking is also that for maximum readability, you want to make each directive as dense as possible. That is to say, padding here is easier to read than the margin:

div.foo {
    padding: 1em;
    margin-top: 1em;
    margin-bottom: 1em;
    margin-left: 1em;
    margin-right: 1em;
}

Having said all that, in general the problem with CSS isn't keeping little individual blocks clean. Your more common problem will be, how do you group rules in files and parts of files?

For example, you could have one layout.css, theme.css (colors, fonts, etc), and individual CSS files affecting specific parts of your application, like data-browser.css. You then import those CSS files from one main CSS file, or you import them on each page as needed.

Upvotes: 0

Tyler Treat
Tyler Treat

Reputation: 14998

There's really no right or wrong answer here, certainly nothing definitive. Do what makes sense to you and is ideally most readable to others.

Personally, I like to group related elements together, but I also organize them by the section in which they are located on the page. I will denote these sections with a comment in the CSS. For example, my header section may look like this:

/* HEADER */

#header {
    float:left;
    width:100%;
    height:162px;
    background:url(images/headerbg.gif);
    background-repeat:no-repeat;
}

#header-left {
    float:left;
    margin:0;
    padding:0;
    width:350px;
}

#header-right {
    float:right;
    margin:0;
    padding:0;
    width:620px;
}

#header a {
    color:#c4e6f2;
    text-decoration:none;
}

#header a:hover {
    color:#ffffff;
}

There's tons of different semantic practices surrounding CSS, but this is just an example of how I generally group my rules. I usually try to minimize the amount of CSS needed, so I use shorthands for borders, margins, padding, etc., and I try not to re-use CSS selectors. I group all properties together usually.

Upvotes: 0

Flack
Flack

Reputation: 5892

I used an own order, convinient for me.

Rules there were listed in the descending order, and the criterion is rule's affect on the layout. For example:

.element {
    float:none;
    position:relative;
    top:-2px;
    z-index:100;
    width:100px;
    height:100px;
    margin:10px 0;
    padding:0;
    border:1px solid #000;
    background:#F00;
    font-size:10px;
    color:#CCC;
}

Of course, in the example above I didn't list all css instructions.

Particular idea was to keep order of groups, such as:

  1. Positioning
  2. Width and height
  3. Margins and paddings
  4. Borders (and others, affecting element's total dimensions)
  5. Backgrounds, aligning (and others, which don't affect whole page's layout)
  6. Typography

Upvotes: 2

cHao
cHao

Reputation: 86505

I'll usually group all properties that apply to the same element together -- it makes it slightly less annoying trying to find everything that applies, and makes it a little easier to keep from duplicating properties. If i have three different .my-class rules, i won't be surprised in the not-so-distant future to find them all setting some property two or three times because someone was rushed and just looked for the nearest selector that looked right.

Upvotes: 1

Daniel T.
Daniel T.

Reputation: 38400

Personally, I use the first method, but I also indent child selectors. For example:

.my-class {
    /* stuff here */
}

    .my-class tr {
        /* stuff here */
    }

        .my-class tr a {
            /* stuff here */
        }

Dunno about best practices though, aside from putting the opening brace on the same line as the closing one, and ending each property with a semi-colon, even if it's the last one.

Upvotes: 0

Related Questions