These CSS Guidelines are applicable to all websites created and managed by Igloo Refrigerator Parts Inc. and under the igloorefrigeratorparts.com domain.

The keywords used in this guide have the following significance:

For accessibility guidelines, please read the Accessibility Guidelines.

You can access the necessary templates and files to start a new project from the "Templates and Assets" section.

Please refer to the Browser Support Guidelines for information on browser support, QA, and tips on how to avoid some common rendering bugs.

2.1 All CSS SHOULD be loaded externally because it enables caching control and makes the HTML smaller.

2.2 External CSS MUST be referenced via the link element, which MUST be placed in the head section of the document as close as possible to the top, but after the title element. This will improve performance and not impede SEO.

2.3 External style sheets MUST NOT be imported using @import because it impairs caching and blocks rendering. Debug files are the only exception to this rule.

2.4 Document head CSS SHOULD NOT be used where a style rule is only required for a specific page. To do so makes these rules uncacheable and inconsistent.

2.5 All linked style sheets MUST exist (you MUST NOT use placeholders). Missing files create unnecessary requests, which may impede performance, and 404 errors, which may impede SEO.

2.6 CSS files SHOULD live in the "css" directory of the website. Images pertaining to the CSS SHOULD live in a directory named "i" within the "css" directory. This makes the "css" directory location-agnostic.

2.7 All CSS files MUST be referenced via @import statements in a debug file, although there MAY be multiple debug files (one global file and one file per section). This aids debugging.

2.8 Served CSS files MUST be concatenated and minified via YUI Compressor in production. The debug files MUST be used as the source for the list of CSS files. This improves performance and improves maintainability.

2.9 You SHOULD use CSS sprites where appropriate. This improves performance because it reduces HTTP requests. This is particularly important when targeting low bandwidth devices.

2.10 You MUST NOT use CSS expressions because browser support is poor and they are not performant.

2.11 You MUST NOT use CSS behaviors (HTC files) because browser support is poor and they create a JavaScript dependency.

2.12 You SHOULD NOT use data URIs because they are larger than their file equivalents and break caching control.

3.1 You SHOULD use UTF-8 character encoding. This helps to avoid localization errors.

3.2 You MUST NOT use inline CSS. To do so makes these rules uncacheable and inconsistent.

3.3 You MUST NOT use !important. It may prevent the good use of user style sheets and makes it hard for other authors to override that CSS declaration.

3.4 You SHOULD NOT create rules using the universal selector (*) as it may have unexpected effects, break inheritance and hamper performance.

3.5 You MUST NOT create rules where the universal selector (*) is used in conjunction with other selectors as it will break inheritance and hamper performance.

3.6 You SHOULD avoid the use of advanced, complex selectors, or CSS3 selectors when a simple class or ID would suffice. Complex selectors can impede performance.

3.7 You SHOULD start with less-specific rules ("p") and add specificity (from right to left) as need arises (".aside p"). This aids in overriding the rules when necessary and keeps rules simple.

3.8 Every HTML tag that will be used MUST have at least a simple CSS element selector with basic style applied to it or there must have been a conscious decision to use the browser defaults (for example, in form elements). This ensures consistency between browsers.

3.8 You SHOULD NOT specify units for values of 0 (zero). These are unnecessary.

3.9 You MUST only use CSS animation for visual decoration, not for functionality. Support for them cannot be depended on.

3.10 You SHOULD test your style sheets for redundant or duplicated selectors.

3.11 Shorthand properties SHOULD be used wherever possible. Be aware that they will override the individual properties.

3.12 You SHOULD NOT modify built files (minified and concatenated files). This can cause confusion, and your changes will be lost.

3.13 Everything other than fonts SHOULD be sized with pixels.

3.14 Every page SHOULD have an ID on the body tag that references that page, so that it can be targeted specifically. For example:

<body id="home">

3.14 Every page MUST have a class on the body tag that references the language and country combination for the language of the page, so that it can be targeted specifically. For example:

<body class="en-us">

4.1 File (the initial comment at the top of the CSS file) and section comments SHOULD follow the CSSDOC (http://cssdoc.net/) format. CSSDOC provides a standardized way of making comments. A CSSDOC comment block (DocBlock) has the following structure:

/**
 * Short description
 *
 * Long description
 *
 * @tags (optional)
 */

4.2 A CSS file MUST include a file comment at the top, including the following information: title of the document, short description, long description (optional), project it relates to, author, copyright, and color information (optional). For example:

/**
 * Christmas theme
 *
 * CSS theme for the Christmas version of the Igloo Refrigerator
 * Parts Inc website
 *
 * This theme should only be used between the dates of November
 * 7th and January 7th
 *
 * @project     IRP Christmas Site
 * @author      Design Team at IRP Inc
 * @copyright   2011 Igloo Refrigerator Parts Inc
 *
 * @colordef    #111111; main text
 * @colordef    #999999; headings
 * @colordef    #9f0000; unvisited links
 * ...
 */

4.3 All related blocks of CSS SHOULD be prefixed with a section comment in this format to aid visual scanning and searchability of the CSS document:

/**
 * Typography
 *
 * @section typography
 **/

Visit the "Templates and Assets" section to access a bare-bones CSS template with comment examples.

4.4 You SHOULD NOT mention version numbers or dates in the comment because the version control system will maintain this information and it is likely to get outdated if it is managed manually.

4.5 You SHOULD maintain a table of contents of the sections in the file. For example:

/**
 * Table of contents
 *
 * Structure
 * Generic typography and lists
 * Global elements
 * Links
 * Forms
 * Tables
 * Visual media
 * Components
 * Reusable
 * One-offs
 */

4.6 Values that require calculations SHOULD have an inline comment showing the necessary steps to arrive at that value. For example:

#main {
        margin-left: 220px; /** aside width + 20px of margin */
}
aside {
        width: 200px;
        float: left;
}

4.7 Properties that need to be updated in different files SHOULD be properly commented. For example, when modifying the min-height property, the height property in IE 6-only style sheets needs to be updated at the same time. A comment alongside both properties should reflect this.

5.1 The opening brace of a rule SHOULD be on the same line as the last selector, with a single space between the selector and the brace. Each property/value pair SHOULD be declared in a separate line with one tab of indentation. The closing brace of a rule SHOULD be on a separate line. Each property SHOULD have a single space between the colon and the property value, and end in a semicolon. Here's an example:

#content {
        color: red;
        font-size: 1em;
}

5.2 Multiple selector rules SHOULD declare one selector per line. Exceptions MAY apply for reset style sheets or other multiple selector rules with many short selectors.

5.3 Vendor-specific properties SHOULD be included after all the other properties to create clear visual distinction. The specified W3C name MUST be declared after the vendor-specific alternatives (for example, border-radius must be declared after -moz-border-radius and -webkit-border-radius).

6.1 Class and ID names MUST be lowercase. Class and ID names SHOULD contain one word only. If necessary, separate words MUST be separated via camel case, as such: highlightModule. Where using camel case and acronyms, if the acronym is at the beginning it should be in lowercase (for example, wwwLink); otherwise uppercase (linkWWW).

6.2 Class and ID names MUST only use alphanumeric characters and hyphens. They MUST NOT include underscores, forward or backward slashes, or asterisks; or begin with a numeric character.

6.3 Class and ID names SHOULD be semantic whenever possible and not presentational. For example, instead of "red" you SHOULD name a warning message style as "warning." You SHOULD always try to use well-recognized class and ID names, such as "nav," "aside," or "footer."

6.4 You SHOULD use microformats or equivalents such as Microdata or RDFa if appropriate uses exist.

6.5 Namespaces MUST be separated from the rest of the class or ID name with a hyphen. For example: "igr-blogWidget", where "igr" is the namespace.

7.1 You MUST choose the font stack carefully (complying with the Branding Guidelines).^[105] Start with the ideal font; followed by a font that is more likely to be installed on users' systems; followed by a font that is installed in most users' systems; and finally one of these default fonts: sans-serif, serif, or monospace.

7.2 Where you are displaying text in uppercase, you MUST convert the text via the text-transform property. This helps with changes of design at a later date.

7.3 Fonts SHOULD be sized using ems, but MAY be sized in % or keyword values. They MUST NOT be sized in pixels, because this breaks the ability to zoom text only.

8.1 When using hex colors, you MUST put them in lowercase because this aids gzipping efficiency.

8.2 You MAY use the following named colors in lowercase: black, white, red, blue. The named colors are easier to read.

8.3 You SHOULD NOT use named colors other than those defined in 8.2 because their values are open to interpretation by developers.

8.4 Elements with an image background MUST have a defined fallback background color. This makes the page easier to use while images are loading and avoids a jarring change of color.

8.5 When using RGBA colors, you MUST declare a fallback hexadecimal color before it so that browsers that do not support RGBA still show a color. You SHOULD NOT use RGBA colors where non-alpha-transparent colors would suffice.

8.6 You MUST NOT use colors for foreground text that are the same color as the background to hide text. This would result in search engines penalizing search results.