views:

418

answers:

12
+8  Q: 

CSS coding style

Are there any good CSS coding style/standards?

+8  A: 

Here is a good one:

http://www.phpied.com/css-coding-conventions/

But the important thing is to pick something and stick with it for consistency.

Andrew Hare
A: 

There's probably loads. At our work we use the following:

/* =div a comment about my div */
div#mydiv {
    border:1px solid #000;
}

The =div allows us to search against all div elements by using the search functionality. There's loads more though, I've used many different variations of this in the past.

Kezzer
what kind of comments do you use for css ?
I.devries
+1  A: 

Check Sass out. It's a template language for CSS that makes your source code DRY:er and mucho easy to read. Even if you're not using ruby you can use it for this task and automate the building of your css files from Sass source. And there are probably Sass implementations in other languages too.

PEZ
+1  A: 

When I code in CSS:

  • In first part I write the class and id
  • In last part I write the general element (p, font, etc) because the class and id have more importance for inheritance
  • I write comment if I want a particular behaviour with IE or with MoSE Browser

You can see some example in CSS Zen Garden

Generally I insert the most important elements over the other: if there's

p.important{/*features of a class*/}

p {/*features of a general element */}

Reading the CSS file I know the format rules before about the most particular elements, after the rules about the most general elements.
It's an habit in programming Java.

alepuzio
I actually think this is exactly the inverse of how you should structure for the exact same reason: class and id having more specificity means tags will have more *effect* and are therefore more important to inheritance
annakata
+1  A: 

Just from experience I used to write quite long CSS style sheets. Now my style sheets typically are half a page.

So keep it simple(KISS), line based (greppable) and keep it compact (use font: instead of font-size etc etc.).

hendry
good points especially compactness
annakata
A: 

The main good coding style is to actually separate css files according to their goals.

See Progressive Enhancement.

That way, whatever coding convention you will choose, you will have consistent and manageable separate css files... easier to debug.

VonC
A: 

In addition to what others said, remember that the C stands for 'Cascading', i.e. subelements inherit from top level elements. Sound simple and straight away. But I have often seen CSS files that contain redundant declarations, e.g. for font styles. This makes a CSS more complex and hard to maintain.

So before you add something to your CSS make sure that it is not redundant, i.e. check parent elements and remove redundant declarations from children.

Given this you should organize your CSS in a way so that high level elements (like declarations for the body class) are mentioned first and more specialized elements last.

Yaba
+7  A: 

I agree with most of the points at Andrew Hare's link, but I strongly believe

.class-name {
    color: green;
}

is inferior to:

.class-name
{
    color: green;
}

on the grounds that:

.class-name, .class-name2 {
    color: green;
}

or:

.class-name, 
.class-name2 {
    color: green;
}

are considerably less obvious to grep or read than:

.class-name, 
.class-name2 
{
    color: green;
}
annakata
never thought about it that way. I think I might start using this convention
Jeff Winkworth
I don't know if that is "considerably less obvious" - this is just the OTBS war all over again.
guns
Well the in-line grouping relies on you spotting the comma in the arbitrarily long selector string and the K+R format makes grepping that little bit harder since not all lines end uniformly - it's an easy thing to fix, why not go with clarity?
annakata
+5  A: 

There's no standard standard, as it were. There are most certainly plenty of in-house standards and conventions. And there are certainly known best practices.

I stick to the following:

  • Structure your CSS according to it's purpose
    That may involve separating out CSS concerns into different files (layout.css, colors.css etc). This may just as well involve clearly dividing up a single CSS file into clear sections along the same lines.

  • Be as specific as possible
    Selectors have differing weights. ID-based selectors are more specific than class-based selectors. Chained selectors (e.g. body div#container div#content p) are very specific indeed.

    Start out being as specific as you can, even if it appears you're being too specific. It's quite easy, later down the line, to merge together two very specific style definitions by removing one and making the other less specific.

    A style definition with loose specificity may target elements you did not intend in ways that are not immediately apparent or obvious. I think this is the most common cause of CSS frustrations ("Why on earth will this div not let me set a top margin?")

  • Always specify every single style you wish to apply for a given defintion
    For example, if you want all your paragraphs to have pink text, set the text colour to pink and also set the margins/padding/background colour/font and so on.

    Don't rely on browser defaults to be suitably consistent. Certainly for the most commonly used elements the main browsers tend to use very similar if not identical default styling.

    If you set all the relevant styles yourself you know what the end result should be.

    If you only set those styles that are most immediately obvious, the end result will be (most likely) a combination of the browser defaults and your styles. This will eventually catch you out at some point. I think this is the second most common cause of CSS frustrations.

  • Use ids for styling unique elements
    It's generally a good idea to apply an id attribute to any unique element that is going to be interacted with in any way. For CSS this will let you apply suitably specific styles more easily.

  • Use an id on a unique page
    Pages that are significantly different in style and layout to the majority (homepage, search results, 404) should have an id on the body element. This gives you the specificity you need to ensure that your careful homepage styling doesn't get affected by styles you later apply to some internal content page.

Jon Cram
A: 

Pretty coding style VS site speed

I've been working with pretty huge CSS files, and found out some pretty interesting things that I've never read about before.

@import

One thing is using @import. That's actually a bottleneck - by going away from using @import completely, the site got a lot more snappy.

#every .style { in one line }

When the browser reads a document, it reads line by line, so by switching from my pretty coding style to this, I accomplished 2 things;

  1. A even more snappy site
  2. Less scrolling, better overview. Why? Cause I first scroll down to find the style I'm going to work with, then it's all in the same line and it's not hard to scroll your eyes along the line to find what you're looking for.
olemarius
I can't imagine in a modern browser that you would get that much of a performance benefit from putting your classes in a single line; can you give an example of how much of a performance gain you were seeing? I would favor well formatted code over compact code, even for a modest performance gain.
Ryan Guill
+1  A: 

Put your css rules (ex: "color: red;") in alphabetical order and also put your selectors (ex: "div { color: red; }") in order they appear in your markup. Separate code for structure from skin.

presario
A: 

This might also be helpful, a few tips to keep your CSS styles DRY - as in "Don't Repeat Yourself" link text