最近試している Sass の書き方

最近、Sass 3.2 (プレリリース版) を使って新しい書き方を模索しているんですが、その方向性に自信が持てないので、ちょっとさらしてみて反応を見ようという試みです。

まず基本的な方向として、以下のような考え方を参考にしています:

• なぜ @kotarok さんは mixin より extend を推すのか - mixi Engineers' Blog
• Sassの存在意義 - Weblog - hail2u.net
• Sassの存在意義への補足 - Weblog - hail2u.net

マークアップに合わせてスタイルを書くのでもなく、スタイルに合わせてマークアップするのでもない、それぞれを適切に書いた上で結びつける、というようなことを僕なりにやろうとしています。スタイルの実装と、それらを利用するためのインターフェイスを分離する、みたいなイメージで、具体的には Placeholder (%) セレクタと @extend を中心にしたものです。

// _breadcrumbs.scss

%breadcrumbs {
    backgrund-color: $palegray;
}

%breadcrumbs-link {
    text-decoration: none;
    &:hover {
        text-decoration: underline;
    }
}

%breadcrumbs-separator {
    color: $gray;
}

%breadcrumbs-current {
    font-weight: bold;
}

例としてパンくずナビゲーションのスタイルを考えてみます。まずこのように % セレクタを使ってスタイルをパーツに分解して書き下ろします。このとき、マークアップの要素タイプやクラス名や入れ子構造などは考えず、ただ必要なスタイルに名前をつけていく感じです。これをたとえば _breadcrumbs.scss というファイルにしておきます。

_breadcrumbs.scss はスタイルを定義しているだけで、それだけでは CSS を生成しません。CSS を生成する Sass ファイルとして style.scss を用意し、_breadcrumbs.scss を @import し、そしてマークアップとスタイルを @extend を使ってつなぎ合わせます。

<div class="crumbs-nav">
    <a href="/">Home</a> <span class="separator">›</span>
    <a href="/artist">Artist</a> <span class="separator">›</span>
    <em>Bobby Womack</em>
</div>

マークアップがこのようなものだったとします。このとき、マークアップは _breadcrumbs.scss のスタイル定義を気にする必要はなく、(ひとまず) 妥当なマークアップであれば良いです。そして style.scss では以下のように書きます。

// style.scss

@import "breadcrumbs";

.crumbs-nav {
    @extend %breadcrumbs;
    a {
        @extend %breadcrumbs-link;
    }
    .separator {
        @extend %breadcrumbs-separator;
    }
    em {
        @extend %breadcrumbs-current;
    }
}

スタイル定義はマークアップに依存しないので、たとえばパンくずが div.crumbs-nav ではなく ol だったり #pankuzu だったりしても、手を入れるのは style.scss の一部だけです (とは言え、スタイルを適用するのに要素が足りなかったり、スタイルの調整が必要な場合もあります)。この調子であらゆるスタイルをそれぞれモジュールとして定義し、style.scss 上でそれらをインクルードし、マークアップと結びつけていきます。その結果、CSS が 1 行も書かれていない style.scss と多数の Sass モジュールが出来上がります。

こうするとまずスタイルを定義する人とマークアップする人の分業がやりやすくなるはずというのがありますが、なによりマークアップとスタイルがそれぞれを束縛し合ったまま足踏みしているような状況から抜け出すきっかけになるのでは、というのが大きいです。

加えて、「このスタイルは汎用的なものか」「どこかで使い回す可能性があるか」みたいなことをいちいち考えず、すべてのスタイルをフラットなモジュールとして捉えられるというのも特徴です。これは良いことなのかちょっと微妙とも思いますが。

これでマークアップ、スタイル、そして両者を結びつける役割が分離できてめでたしめでたし、と言いたいところですが、スタイル定義を一切含まず、ひたすら @import と @extend を繰り返すだけのファイルを見ていると、なんだか遠いところに来てしまったような気がして言い知れぬ不安を覚えます。とくにひとりでフロントエンドすべてを面倒見るような規模の場合、このやり方だとメリットが見えにくいというか、実際に僕が今ひとりでこうやっていて、いったいどこに向かってるんだろうかという気持ちになったのでこの記事を書いています。

あとファイルをどんな感じで分割するか、@import はどうやるのが良いか (ファイルの先頭にまとめてかそのつどか) といったあたりも悩むところです。どこに何を書いたかすぐに分からなくなるし。

ちなみに、実際にこのやり方で書いてみるとふつうの CSS の 3 倍手間がかかるし、3 倍頭を使いますが、それはむしろ良いことだと考えているというか、そういうものだという理解です。「ウェブ標準」が流行ったときに structure と presentation の分離ということが盛んに言われましたが、結局のところただ HTML と CSS のファイルが分離できただけでは、という気がしていた者としては、ある種の手応えはあるし、そのうち何かが見えてくるはず、とは思います。

皆さん、どんなふうに書いてますか?