Summary of CSS Coding Guidelines - ΩJr. Coding Guidelines

Know your CSS
CSS basics, from the Web Standards Curriculum.


Avoid depending on CSS for critical functionality
Add server-side intelligence.


Get along with clients on all kinds of devices

• Measure in em fractions or percentages where possible. This will ensure cross-resolution compatibility.
  
• Otherwise, measure your font sizes either completely relatively (in % or em), or completely absolutely in points.
  
• Limit the width of the main content based on readability and usability.
  
• Avoid browser hacks inside the CSS. If necessary, use vendor-specific prefixes, and put them in their own highly visible place, and document them well. If possible, use Html or CSS Conditional Comments, or even Javascripted feature detection.
  
• Provide vendor-specific rules for all vendors, and provide the general rule as well, as the last of the set. Currently known vendor prefixes: -moz, -ms, -o, -webkit. Keep them in alphabetical order. Always end the series with the generic rule.
  
• Apply CSS3 and vendor-specific techniques to reduce the dependency on images.
  
• Always provide CSS rules for printing. Get your client to determine which elements need to show up in print.

Like so:

/* Samples taken from Zjramble5, used with permission */

body { 

  max-width: 600pt;

  margin-left: auto;

  margin-right: auto;

}

button {

  font-size: 14pt;

  height: 28pt;

  font-weight: bold;

  margin: 0;

  padding: 0pt 4pt;

  width: auto;

  min-width: 49pt;

  text-align: center;

  cursor: pointer;

  -webkit-tap-highlight-color: rgba(4,96,179,0.3);

  -webkit-appearance: none;

  color: #fff;

  background-color: #000;

  background-image: url(myBadlyShapedLowResButtonImage.png);

  background-image: -ms-linear-gradient(  rgb(255,255,255), 

                                          rgba(255,255,255,0));

  background-image: -moz-linear-gradient( rgb(255,255,255), 

                                          rgba(255,255,255,0));

  background-image: -o-linear-gradient(   rgb(255,255,255), 

                                          rgba(255,255,255,0));

  background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, 

                                     from(rgb(255,255,255)),

                                       to(rgba(255,255,255,0)));

  background-image: linear-gradient(      rgb(255,255,255), 

                                          rgba(255,255,255,0));

  -moz-text-shadow: 0pt -1pt 1pt #111;

  -ms-text-shadow: 0pt -1pt 1pt #111;

  -o-text-shadow: 0pt -1pt 1pt #111;

  -webkit-text-shadow: 0pt -1pt 1pt #111;

  text-shadow: 0pt -1pt 1pt #111;

}

Get along with CMS implementors

• CMS editors can change page titles and descriptions. What may seem like fixed widths and heights due to Visual Designs, may require dynamic width and height flexibility.
  
• Most CMS-es can resize images to fit the Visual Design, either automatically or manually, but take into consideration that those resizers tend to measure in pixels.
  
• Most CMS-es will specify whether some elements are to be shown or hidden, based on search criteria, personalisation, or publication dates. Take that into consideration when designing element and word flow.
  
• Some CMS-es allow editors to specify whether some elements are to be shown or hidden. Programmatically, those differences may be rendered using the same HTML template. Take that into consideration when designing element and word flow.
  
• On indentation. Most CSS generators group rules about the same element. Do repeat that. Some CSS generators like to indent follow-up rules concerning child elements or pseudo selectors. Avoid that.
  
• Maximize cascades, reduce overrides.
  
• CMS-es tend to sport their own Wysiwyg editor. Define a space for user-added elements inside the page html, and prevent cross-contamination of style rules.
  
• Provide a CSS for the CMS' Wysiwig editor, that reflects the visual display of the web page.
  
• If possible, concatenate multiple files into 1, in cascade order. During development, you can use @import. The CMS implementor (or whoever actually brings the page live) will replace these with copies of the dereferenced files.

Adding CSS to your web pages
<link rel="stylesheet" title="myStyle" media="all" type="text/css" href="myStyle.css?20111020T1616" />

Or:

<style type="text/css" id="myStyle">/* <![CDATA[ */

body{ 

  background-color: #fff; 

  color: #000;

}

/* ]]> */</style>

Start big, end small
Blatantly copied from WNAS CSS Coding Conventions: start defining the largest elements, and work your way towards more specificity. At the top of your CSS we should find html and body, and as we read our way down, the elements and selectors should become smaller and more specific.

Wrong:
a{}
li{}
ul{}
p{}
body{}
html{}

Better:
html{}
body{}
div{}
p{}
ul{}
li{}
a{}


On tables
Use tables for tabular data. Prefer the use of semantically relevant elements, like article, aside, header, footer, hgroup, menu, and structurally relevant CSS properties like column-width, but consider the supported browsers.


Avoid procedural rules where declared rules work
Sometimes we want to use Javascript (libraries) to set CSS or create animations. If you can use a CSS rule declaration instead of a scripted procedure, do so. (Do take ease of development into consideration, and talk to the Javascript developers.)

If you must use Javascript to set CSS, do so by adding or removing a CSS class, rather than each property individually (or the whole CSS rule for that element at once).


Use short-hand notation where possible

Example of full notation:
.myBlock { background-color: transparent; background-image: url(myImage.png); background-attachment: scroll; background-repeat: no-repeat; background-position: center center; }

Example of short-hand notation:
.myBlock { background: transparent url(myImage.png) scroll no-repeat center center; }

However, when setting just one property, using short-hand is wrong, because it will overrule the other implied properties.


Remember a background colour
Help the visitor: provide a background colour.

Wrong:

body{

  font-size: medium;

  padding: 8pt;

}

p{ 

  padding: 8pt;

  margin: 8pt 0pt 16pt;

  color: #000;

}

a{ color: blue; }

Better:

body{

  font-size: medium;

  padding: 8pt;

  background-color: white;

}

p{ 

  padding: 8pt;

  margin: 8pt 0pt 16pt;

  color: #000;

}

a{ 

  color: blue; 

  background-color: white;

}

Even better:

body{

  font-size: medium;

  padding: 8pt;

  color: #000;

  background-color: white;

}

p{ 

  padding: 8pt;

  margin: 8pt 0pt 16pt;

}

a{ 

  color: blue; 

  background-color: white;

}

Remember contrast
Colour Contrast Check


Put rule properties together that make sense together
And be consistent about it. Whether some selectors and properties make sense together, depends on the web page, so it will differ per project.

Wrong:

p.error{

  color: #111;

  border: none;

  text-decoration: underline;

  padding: 8pt;

  background-color: #ecc;

  font-style: italic;

}

Better:

p.error{

  color: #111;

  background-color: #ecc;

  font-style: italic;

  text-decoration: underline;

  padding: 8pt;

  border: none;

}

On whitespace and block style for selectors and properties

• Do not use spaces inside class names or element IDs, for those spaces already act as selector separators (but you knew that already).
  
• Group rules about the same selector together, dividing it from the rest with blank lines.
  
• Put each selector in a groups of selectors on its own line.
  
• Put each property on its own line, unless you require the spatial benefits of comparison.
  
• Provide spaces after operators and before opening braces, except when the operator is part of a pseudo-selector.
  

/* no comparison needed */

fieldset {

  background-color: #ddd;

  color: #000;

  border: 1pt solid black;

  border-radius: 5pt;

  margin: 8pt;

  padding: 8pt;

}



/* comparison needed */

fieldset#gameStart  { background-color: #ffc; }

fieldset#gameActive { background-color: #9d9; }

fieldset#gameOver   { background-color: #600; color: #fff; }

Provide semantically relevant class names and element IDs
Name classes and elements after what they are used for in the web page. Be as specific as needed. What proves semantically relevant, depends on the type of page.


Use camel casing for class names and element IDs
Normally we would add a space to signify the start of new words. Since CSS class names and element IDs must not contain spaces, we advise camel-casing: concatenate all the words in a class name and start each word with a capital letter, except for the very first one, which must start with a lower case letter. Avoid underscores, hyphens, and other marks. These are camel-cased, and on some pages also semantically relevant class names:
leftSidebarBlock
footerServiceLink
newsArticleButton


Use consistent colour value casing
Some guidelines will tell you to use upper case for hexadecimal colour values. This guideline doesn't care, as long as you stick with the choice you made.


Prepend your CSS files with a JavaDoc-like comment block
Preferably one that holds useful information, e.g.:
/**
* myStyle.css
* @use For template: thisPageType
* @author Our company <us@here.now>
*/


Use a CSS validator
It will find grammatical and some usability errors. It will not find functional errors. Use common sense and browser-comparison services for functional testing.