1.4. CSS, LESS and Styles

The CSS Coding conventions are inspired by Stoyan Stefanov’s CSS Coding Conventions

Many of them are automatically checked using scame which is now included in the CSS Coding Convention Checker. Please report any problems that you have with running paver lint or if some errors are not identified by paver lint

1.4.1. CSS Syntax Elements

When describing the CSS rules, we will use the following terminology.

CSS Selector Graphic

1.4.2. General

  • Use C++ comments style (/* comment here */) and not C style (//) as they are not supported by CSS2 and there are problems in some browsers. Also, on LESS C style comments (//) are ignored in the final result.
  • Avoid using short CSS notation. They are harder to read and the diff generated by changing short notations is less explicit.
  • Avoid using IDs when defining styles as they discourage style reuse… and then you take the risk of repeating yourself.
  • Put general styles in ‘’styles.css’’ and don’t put page specific styles.
  • Page specific styles can be included using a different file.
  • Use uppercase characters for HEX RGB color codes. (eg. Good #F9A0C5 - BAD #f9a0c5)
  • Don’t use color names or RGBA, just HEX code.
  • Use 4 space indentation.
  • End every property-value with a semi-colon.
  • Separate each rule by a blank line.
  • Put unrelated rules in different files.
  • LESS constants (variables) should be dahs-separated and only low cases: @good-constant

1.4.3. CSS Class naming

  • The most important thing to have in mind is the content nature of the HTML document, not its presentation. Selector names should describe the content semantic and not how it looks.
  • Don’t use abbreviation. Use ‘header’ instead of ‘hdr’ or ‘head’.
  • Avoid presentation-specific words in the name, like blue, text-gray, or light-box.
  • Add namespaces using a dash (-) as a separator.
  • Distinct words in the class name are separated by a dash.
  • Names are lowercase.

1.4.4. Rules definition

  • The property will be followed by colons and then a space.

Good:

.some-class {
    float: center;
}

Bad:

.some-class {
    float:center;
}
  • Put each selector on a single line and separate them using commas. This makes it easier to see each selector when using multiple selectors.

Good:

.some-class,
p a.class {
    float: center;
}

Bad:

.some-class, p a.class {
    float: center;
}
  • The closing brackets should be on their own line. They should not be wrongly indented.

Good:

.some-class {
  float: center;
}

Bad:

.some-class
{
    float: center;
    }

.some-class {
    float: center; }

.some-class, .another { float: center; }
  • The opening bracket should be on a the same line as the last selector.

Good:

.some-class {
    float: center;
}

.some-class,
.another-class {
    float: center;
}

Bad:

.some-class
{
    float: center;
}

1.4.5. Layout and Typography separation

  • Don’t put typography properties in the same class as layout properties
  • The idea it that when you change or remove a typographic rule, the layout will not be affected.
  • Use this with moderation, sometimes it is ok to set a margin or padding for h1 or p tags… but don’t abuse this.

GOOD:

.product-name {
    font-style: underline:
    color: red;
}

.highlighted-box {
    float: center;
    width: 30px;
    background-color: blue;
}

BAD:

.product-name {
    font-style: underline:
    color: red;
    float: center;
    width: 30px;
    background-color: blue;
}