108 lines
4.4 KiB
Markdown
108 lines
4.4 KiB
Markdown
|
---
|
|||
|
|
title: Best practices
|
|||
|
|
crumb: Best practices
|
|||
|
|
layout: tutorial
|
|||
|
|
---
|
|||
|
|
### Use a Base stylesheet file
|
|||
|
|
|
|||
|
|
Create a `_base.scss` [partial][1] to initialize your stylesheets with common
|
|||
|
|
variables and ([often][2]) the framework utilities you plan to use:
|
|||
|
|
|
|||
|
|
#### _base.scss
|
|||
|
|
|
|||
|
|
$blueprint_grid_columns = 24
|
|||
|
|
$blueprint_grid_width = 30px
|
|||
|
|
$blueprint_grid_margin = 10px
|
|||
|
|
$font_color = #333
|
|||
|
|
|
|||
|
|
@import compass/reset.scss
|
|||
|
|
@import compass/utilities.scss
|
|||
|
|
@import blueprint/screen.scss
|
|||
|
|
|
|||
|
|
// etc.
|
|||
|
|
|
|||
|
|
The `_base.scss` file is also a great place to keep your own custom mixins, so
|
|||
|
|
they’re available to any stylesheet that includes it.
|
|||
|
|
|
|||
|
|
Then you can include this file in all other stylesheets:
|
|||
|
|
|
|||
|
|
#### application.scss
|
|||
|
|
|
|||
|
|
@import "base";
|
|||
|
|
|
|||
|
|
#wrapper {
|
|||
|
|
@include container;
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
// etc.
|
|||
|
|
|
|||
|
|
It is important to define any compass/framework constants that you want to override
|
|||
|
|
in base.scss first, before @import-ing the framework files. See [Overriding
|
|||
|
|
Constants][3] , for an example of where the number of grid columns for blueprint
|
|||
|
|
is overridden/set to 32. Note that you can refer to `_base.scss` without the
|
|||
|
|
leading underscore and without the extension, since it is a [partial][1].
|
|||
|
|
|
|||
|
|
### Write your own Custom Mixins
|
|||
|
|
|
|||
|
|
Mixins let you insert any number of style rules into a selector (and its
|
|||
|
|
descendants!) with a single line. This is a great way to [DRY][4] up your
|
|||
|
|
stylesheet source code and make it much more maintainable. Using mixins will
|
|||
|
|
also make your stylesheet look like self-documented source code -- It’s much
|
|||
|
|
more obvious to read something like `@include round-corners(6px, #f00)` than the whole
|
|||
|
|
list of rules which define that appearance.
|
|||
|
|
|
|||
|
|
#### Presentation-free Markup
|
|||
|
|
|
|||
|
|
CSS was created to extract the presentational concerns of a website from the
|
|||
|
|
webpage content. Following this best practice theoretically results in a website
|
|||
|
|
that is easier to maintain. However, in reality, the functional limitations of
|
|||
|
|
CSS force abstractions down into the markup to facilitate the [DRY][4] principle
|
|||
|
|
of code maintainability. Sass allows us to move our presentation completely to
|
|||
|
|
the stylesheets because it let's us create abstractions and reuse entirely in
|
|||
|
|
that context. Read [this blog post][5] for more information on the subject.
|
|||
|
|
|
|||
|
|
Once you have clean markup, style it using Mixins and Inheritance. With clean
|
|||
|
|
and clear abstractions you should be able to read stylesheets and imagine what
|
|||
|
|
the webpage will look like without even loading the page in your web browser.
|
|||
|
|
|
|||
|
|
If you find your CSS is getting too bloated due to sharing styles between
|
|||
|
|
semantic selectors, it may be time to refactor. For instance this stylesheet
|
|||
|
|
will be unnecessarily bloated:
|
|||
|
|
|
|||
|
|
@mixin three-column {
|
|||
|
|
.container { @include container; }
|
|||
|
|
.header,
|
|||
|
|
.footer { @include column(24); }
|
|||
|
|
.sidebar { @include column(6); }
|
|||
|
|
article { @include column(10); }
|
|||
|
|
.rightbar { @include column(8); }
|
|||
|
|
}
|
|||
|
|
body#article,
|
|||
|
|
body#snippet,
|
|||
|
|
body#blog-post { @include three-column; }
|
|||
|
|
|
|||
|
|
Instead, ask yourself "what non-presentational quality do these pages share in
|
|||
|
|
common?" In this case, they are all pages of content, so it's better to apply a
|
|||
|
|
body class of "content" to these pages and then style against that class.
|
|||
|
|
|
|||
|
|
#### Nest selectors, but not too much.
|
|||
|
|
|
|||
|
|
It's easier to style a webpage from scratch or starting from some common base
|
|||
|
|
point for your application than it is to contend with unwanted styles bleeding
|
|||
|
|
into your new design. In this way, it is better to use some basic nesting of
|
|||
|
|
styles using some selector early in the markup tree. And then to refactor as patterns of use emerge to reduce bloat.
|
|||
|
|
|
|||
|
|
It's important to remember that long selectors incur a small rendering
|
|||
|
|
performance penalty that in aggregate can slow down your web page. There is
|
|||
|
|
no need to exactly mimic your document structure in your css. Instead nest
|
|||
|
|
only deep enough that the selector is unique to that part of the document.
|
|||
|
|
For instance, don't use `table thead tr th` when a simple `th` selector will
|
|||
|
|
suffice. This might mean that you have to separate your styles into several
|
|||
|
|
selectors and let the document cascade work to your advantage.
|
|||
|
|
|
|||
|
|
[1]: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#partials
|
|||
|
|
[2]: http://groups.google.com/group/compass-users/browse_frm/thread/0ed216d409476f88
|
|||
|
|
[3]: http://wiki.github.com/chriseppstein/compass/overriding-constants
|
|||
|
|
[4]: http://c2.com/cgi/wiki?DontRepeatYourself
|
|||
|
|
[5]: http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters/
|