Every project needs some organization. Throwing every new style you create onto the end of a single file would make finding things more difficult and would be very confusing for anybody else working on the project.
See also
There are several ways of organizing CSS into files. Whereas traditionally it was easier to put all the styles for a single site either into a single file or to simply concatenate and compress a bunch of files, modern style languages like Sass and Less allow for much smarter and potentially faster ways to set things up.
One way to setup a (S)CSS file structure is a combination of an ‘onion’ and a modular pattern. The modular pattern assures maximal reusability of design patterns and common solutions to common problems (DRY). The onion model helps us steer clear of precedence issues.
While being a work in progress, the import order in a hypothetical main.scss would look as follows:
// Modular mixins. These should generate no CSS of themselves but merely
// make mixins, variables and functions available and can be reused
// from site to site.
@import "buttons";
@import "shades";
...
// Project-specific modules (again: not producing any actual CSS output)
@import "variables";
@import "colours";
@import "fonts";
// Common site-wide components
@import "reset"; // Browser reset
@import "tags"; // Tag selectors
@import "grid"; // Grid system
@import "classes"; // Common classes (object-based / SMACSS)
@import "ids"; // Common ID-referenced styles (keep these to a minimum)
// App-specific overrides of common ids and classes
// (Try to minimize tag selectors here)
@import "admin";
@import "shop";
@import "blog";
...
// Media-specific overrides of tags, classes, apps and grid.
@import "media";
Warning
This is a very early sketch of a mere candidate of a CSS structure which is untested and not yet ready for actual implementation. Unless you’re brave.
See also
See also
CSS Specificity is one of the most difficult concepts to grasp in Cascading Stylesheets. The different weight of selectors is usually the reason why your CSS-rules don’t apply to some elements, although you think they should have.
Every selector has its place in the specificity hierarchy. There are four distinct categories which define the specificity level of a given selector:
See also
A CSS Reset (or “Reset CSS”) is a set of CSS rules that resets the styling of all HTML elements to a consistent baseline across browsers.
Todo
Include one of the following alternatives as bad practise and the others as explicitly deprecated.
See also
A modern, HTML5-ready alternative to CSS resets.
Normalize.css makes browsers render all elements more consistently and in line with modern standards. It precisely targets only the styles that need normalizing.
Sass is an extension of CSS that adds power and elegance to the basic language. It allows you to use variables, nested rules, mixins, inline imports, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized, and get small stylesheets up and running quickly, particularly with the help of Compass.
See also
As of 3.2 (the current release), Sass has smart support for CSS3 media queries. This allows for patterns like:
$information-phone: "only screen and (max-width : 320px)";
@media #{$information-phone} {
background: red;
}
This compiles to:
@media screen and (max-device-width: 320px) {
background: red;
}
Compass is a CSS authoring framework based on Sass providing:
See also
Several grid systems exist to make the life of web designers easier. We currently recommend the usage of the Susy responsive grid system, unless Twitter’s Bootstrap is used, which works better with the already included grid system.
Susy is a responsive grid system for Compass.
See also
For modern web development, we have to account for several types of viewports:
In responsive designs we generally want an ideal viewport and adjust the elements to the available pixels instead of zooming the whole site. For this we use the viewport meta tag in the HTML header to disable zoom and set the width of the layout viewport equal to that of the device:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
For full-screen applications which are not meant to scroll, also set the height of the viewport to the device height:
<meta name="viewport" content="width=device-width, height=device-height, initial-scale=1, maximum-scale=1, user-scalable=no">
Note
The device pixels (device-width and device-height) are not necessarily equal to actual screen pixels due to the device pixel ratio. See Device Independent Pixels.
See also
Todo
There are several references here, with varied quality and usability. Please remove what’s not usable and summarise the useful bits.
See also
devicePixelRatio is the ratio between physical pixels and device-independent pixels (dips) on the device:
window.devicePixelRatio = physical pixels / dips
See also