Our principles for BEM + Sass - 14islands
14islandsはresponsive.ioを運営している、スウェーデンのフロントエンドWeb開発会社。
- 14islandsではMindBEMdingベースのアプローチを採用
- Sassも使っている
- BEM+SassでCSSを構造化するためにいくつかの原則がある
原則1 セレクタにはIDでも要素でもなくクラスを用いる (Classes as selectors, not ids or element tags)
- セレクタには、IDや要素（タグ）ではなくCSSクラスを使っている
- ID
- フラグメント識別子やJavaScriptのフックとしても気軽に使われるのでCSSをIDと紐づけるのはよくない
- IDはセレクタとして高速に機能すると言われるが、クラスと比べても意味のある差異が出ることはほとんどない
- 要素（タグ）
- セマンティックなマークアップとしては有用だが、セレクタには適していない
- 遅いし、異なる要素に同じスタイル郡を適用する際に柔軟性がない
<a>、、`の各要素にボタンデザインを適用する場合など
- CSSクラスは変更したりスタイルをミックスするのも容易で、コードをモジュラーに保つのに最適
- クラスをセレクタとして使うことの主なリスク
- 2つの異なるクラスが同じ名前となって衝突する可能性
- BEMによってプレフィクスと命名規約が導入されることで防止できる
原則2 フラットに保つ
- ルール：CSSを2段階よりも深くネストしない
- それ以上になると結合して変更が難しくなる
- 実際は1階層が望ましい
- より多くのクラスが必要となるが柔軟性は上がる
- Sassによって、すべての状態（state）を同じCSSクラス内に含めておける
以下はsearch inputを含むtoolbarモジュールのマークアップとSassの例。ツールバーがアクティブな状態の時だけ、検索入力欄が見えるようにしたいので、Sassのparent selector (&)を使って、toolbar--activeという親の状態を検出できるようにする。
(Work in progress)
原則3 モジュールに分割する
われわれはいつも、ファイルを最小に保って大きく成長していかないようにするため、モジュール毎に1つのファイルを作成している。例えば、toolbarモジュールはtoolbar.scssというファイルになる。
とはいえ、プロジェクトの復数の箇所に適用される一般的なクラスについてのCSSファイルもいくつかある。
ファイルの例：
- グロバールなレイアウトのためのスタイル
layout.scss - すべてのフォントスタイル
typography.scss - フォーム要素のためのスタイル
forms.scss
この考え方はSMACSSの構造と実によくマッチするし、理解もしやすい。 The general rule is to use common sense on how to break down these files.
このコンセプトをもう少し広げるために、プロジェクト内の関連するファイルにも同じ名前を付けてみている。例えば、同じ機能に関係するJavaScriptモジュールとサーバーサイドのパーシャルテンプレートなどだ。
例：
toolbar.html.erbサーバーサイドのパーシャルテンプレートtoolbar.jsJavaScriptモジュールtoolbar.scssSassモジュール
こうすることで、プロジェクト内で関連するコンポーネントを探すのが容易になる。
原則4 DRYにする
DRY (Don't Repeat Yourself)はプログラミングにおける一般的な慣習で、Sassのコードにも適用できる。
In Sass we can use variables to store common values in one place. Variables in CSS are being introduced but a common browser support is still a thing of the future.
Variables are more readable then colour codes or random numbers. Lets use our loved toolbar example and DRY it up, the code will look something like this:
<script src="https://gist.github.com/hjortureh/8006074.js"></script>The first thing you will notice is that we have a global variables.scss file that stores all variables on the project. The module name is also a variable since we use it multiple times in the file.
Notice how this makes the code more descriptive and easier to read.
おまけの原則 スタイルガイド
As a bonus principle: It’s very useful to create a style guide to have a quick overview of all the styles within a give project. Style guides are just simple HTML document that include all the visual elements of a project with all possible states. This is usually quick to create, but requires a team effort to keep up to date. We recommend it, specially on responsive projects where some elements have multiple states depending on multiple breakpoints. Be careful out there.