Where possible, limit CSS files width to 80 characters. Reasons for this include
- the ability to have multiple files open side by side;
- viewing CSS on sites like GitHub, or in terminal windows;
- providing a comfortable line length for comments.
- Use soft-tabs with a two space indent. Spaces are the only way to guarantee code renders the same in any person's environment.
- Put spaces after : in property declarations.
- Put spaces before { in rule declarations.
- When grouping selectors, keep individual selectors to a single line.
- Place closing braces of declaration blocks on a new line.
/* Bad CSS */
.selector, .selector-secondary, .selector[type=text] {
padding:15px;
margin:0px 0px 15px;
background-color:rgba(0, 0, 0, 0.5);
box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF
}
/* Good CSS */
.selector,
.selector-secondary,
.selector[type="text"] {
padding: 15px;
margin-bottom: 15px;
background-color: rgba(0,0,0,.5);
box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;
}
- Lowercase all hex values, e.g., #fff. Lowercase letters are much easier to find when scanning a document as they tend to have more unique shapes.
- Use shorthand hex values where available, e.g., #fff instead of #ffffff.
- Avoid specifying units for zero values, e.g., margin: 0; instead of margin: 0px;
Related property declarations should be grouped together following the order:
- Positioning
- Box model
- Typographic
- Visual
Positioning comes first because it can remove an element from the normal flow of the document and override box model related styles. The box model comes next as it dictates a component's dimensions and placement.
Everything else takes place inside the component or without impacting the previous two sections, and thus they come last.
.declaration-order {
/* Positioning */
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 100;
/* Box-model */
display: block;
float: right;
width: 100px;
height: 100px;
/* Typography */
font: normal 13px "Helvetica Neue", sans-serif;
line-height: 1.5;
color: #333;
text-align: center;
/* Visual */
background-color: #f5f5f5;
border: 1px solid #e5e5e5;
border-radius: 3px;
/* Misc */
opacity: 1;
z-index: 1;
}
Compared to s, @import is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach:
- Use multiple elements
- Compile your CSS with a preprocessor like SASS or Less into a single file
Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future. Here's a typical setup.
element { ... }
.element-avatar { ... }
.element-selected { ... }
@media (min-width: 480px) {
.element { ...}
.element-avatar { ... }
.element-selected { ... }
}
When using vendor prefixed properties, indent each property such that the declaration's value lines up vertically for easy multi-line editing. In Sublime Text 2, use Selection → Add Previous Line (⌃⇧↑) and Selection → Add Next Line (⌃⇧↓).
/* Prefixed properties */
.selector {
-webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
box-shadow: 0 1px 2px rgba(0,0,0,.15);
}
In instances where a rule set includes only one declaration, consider removing line breaks for readability and faster editing
/* Single declarations on one line */
.span1 { width: 60px; }
.span2 { width: 140px; }
.span3 { width: 220px; }
.icon { background-position: 0 0; }
.icon-home { background-position: 0 -20px; }
.icon-account { background-position: 0 -40px; }
ID names should be in lowerCamelCase. Avoid using ID's in your CSS files. Keep ID's for your Javascript
#pageHolder {
}
Class names should be in lowercase, with words separated by dash.
.my-element {
}
Object oriented CSS (OOCSS) is a methodology of writing reusable CSS that is fast, scalable and maintainable. It’s done using two main principles: separating structure from skin and container from content.
-
Separating structure from skin means to abstract the structure and positioning styles of an object from the presentational styles, or skin or theme.
-
Separating container from content means to break components’ dependency of their containers. Any object should be able to be placed in another container and still look and behave the same.
The performance benefits of OOCSS should be fairly clear. If you have fewer styles that are repeated in your CSS, then this will lead to smaller file sizes and thus faster downloading of those resources.
There are many techniques that you can use with OOCSS like SMACSS (calable and Modular Architecture for CSS), BEM (block, element, modifier), SUIT and many more. But the whole idea behind is to write resuable code.
The naming convention follows this pattern:
.block {}
.block__element {}
.block--modifier {}
- .block represents the higher level of an abstraction or component.
- .block__element represents a descendent of .block that helps form .block as a whole.
- .block--modifier represents a different state or version of .block.
The reason for double rather than single hyphens and underscores is so that your block itself can be hyphen delimited, for example:
.site-search {} /* Block */
.site-search__field {} /* Element */
.site-search--full {} /* Modifier */
.site-search--compact {} /* Modifier */
So that’s BEM (or a slight variation thereof); a highly useful, powerful and simple naming convention to make your front-end code easier to read and understand, easier to work with, easier to scale, more robust and explicit and a lot more strict.
For all BEM looks a little odd, it as a hugely valuable addition to the front-end developer’s toolbox, no matter the project.
http://jsbin.com/fimizu/79/edit
http://jsbin.com/wasobi/85/edit
SUIT CSS is a reliable and testable styling methodology for component-based UI development.
The CSS responsible for component-specific styling.
Syntax: [-][--modifierName|-descendentName]
The component's name must be written in pascal case. Nothing else in the HTML/CSS uses pascal case.
.MyComponent { /* … */ }
<article class="MyComponent">
...
</article>
A component descendent is a class that is attached to a descendent node of a component. It's responsible for applying presentation directly to the descendent on behalf of a particular component. Descendent names must be written in camel case.
<article class="Tweet">
<header class="Tweet-header">
<img class="Tweet-avatar" src="{{src}}" alt="{{alt}}">
...
</header>
<div class="Tweet-bodyText">
...
</div>
</article>
Use is-stateName to reflect changes to a component's state. The state name must be camel case. Never style these classes directly; they should always be used as an adjoining class.
This means that the same state names can be used in multiple contexts, but every component must define its own styles for the state (as they are scoped to the component).
.Tweet { /* … */ }
.Tweet.is-expanded { /* … */ }
<article class="Tweet is-expanded">
...
</article>
A component modifier is a class that modifies the presentation of the base component in some form (e.g., for a certain configuration of the component). Modifier names must be written in camel case and be separated from the component name by two hyphens. The class should be included in the HTML in addition to the base component class.
/* Core button */
.Button { /* … */ }
/* Default button style */
.Button--default { /* … */ }
<button class="Button Button--default" type="button">…</button>
.MyComponent {}
.MyComponent.is-animating {}
.MyComponent--modifier {}
.MyComponent-part {}
.MyComponent-anotherPart {}
A topic which is—with the quality of today’s browsers—more interesting than it is important, is selector performance. That is to say, how quickly a browser can match the selectors your write in CSS up with the nodes it finds in the DOM.
Generally speaking, the longer a selector is (i.e. the more component parts) the slower it is, for example:
body.home div.header ul {}
...is a far less efficient selector than:
.primary-nav {}
This is because browsers read CSS selectors right-to-left. A browser will read the first selector as
- find all ul elements in the DOM;
- now check if they live anywhere inside an element with a class of .header;
- next check that .header class exists on a div element;
- now check that that all lives anywhere inside any elements with a class of .home;
- finally, check that .home exists on a body element.
The second, in contrast, is simply a case of the browser reading
- find all the elements with a class of .primary-nav.
- Grunt UNCSS
- Minify
- CSS Lint
- Minimizing browser reflow
- Minimize dom depth
- Avoid complex selectors
- Change classes as low in the dom tree as possible
- Apply animations with position fixed or absolute
- Avoid setting multiple inline styles
- Avoid tables for layout
- Avoid JavaScript expressions in the CSS