この投稿は Increments Advent Calendar 2017 の18日の記事です。去年に続き、2017年の Qiita の CSS 構成について述べます。
2016年版はこちら: QiitaのCSS構成2016
プリプロセッサー
2016年は CSS のビルドフローで一貫して PostCSS を使っていましたが、2017年では プリプロセッサーとして Sass (node-sass) を使っています。
プリプロセッサーとして PostCSS を使わなくなった最大の理由は @apply ルールが仕様から落ちた ことです。@apply は Sass でいう引数なしの mixin みたいなもので、Chrome の Canary では実装されていた時期がありましたが、消えてしまいました。
おそらく CSS Nesting Module や CSS Extend Rule も落ちると思われるので、今後標準化されている CSS の構文では冗長でない記述ができないと判断しました。PostCSS のプリプロセッサー用のプラグインの導入の基準は、「今後 CSS の仕様として入る可能性が（少しでも）あるかどうか」だったので postcss-mixins などは使わず、潔く Sass に切り替えました。
Sass はよくできていて便利だし、コミュニティも発達していてなくなる気配を感じません。不満を感じることもありますが、Sass はこういうものだと割り切って書いています。PostCSS の独自プラグインを書いて拡張していたときと比べ、コードの手離れも良くなったと思います。
最適化
PostCSS を完全に捨てたわけではなく、コードの最適化をする際に利用しています。利用しているプラグインは以下の3つです。
最適化のプロセスは去年から変わっていません。近い将来 autoprefixer と postcss-flexbugs-fixes が不要になるのを待ち望んでいます。
コードリント、フォーマット
2016年は CSS のリンターとして Stylelint を使っていましたが、今は使っていません。CSS における機械的なリントというものが何なのかが自分の中で定まらなくなり、デザインの意図通りの記述ができているのかをレビューしています。つまり僕が CSS リンターです。
フォーマッターについては Stylefmt は捨て、Prettier に従うようにしました。
アーキテクチャー
Qiita 開発チームはデータドリブンなので、デザインリニューアルの際も一部のユーザーの皆様にベータ版を使っていただき、そのログやフィードバックから UI を調整しています。
その際、実装した UI を捨てやすくするために、ECSS という設計手法を参考にしています。1
ディレクトリ構成
/stylesheets 以下のディレクトリ構成は以下の用になっています。
$ tree -L 1
.
├── base
├── index.scss
├── mixins
├── namespaces
├── pages
├── settings
├── styleguide.scss
└── utilities
index.scss がアプリケーション用の、styleguide.scss がスタイルガイド用のエントリーファイルです。
settings ではカラーパレットや設定などを Sass のグローバル変数で定義しています。mixins は Sass の mixin を定義しています。ECSS に習ってルールセットはあまり再利用しようとせず捨てやすくしていますが、mixin としてデザインの意図にあった宣言に名前を付けています。
namespaces 以下のディレクトリ構成は次のようになっています。
$ tree -L 1
.
├── Item
├── Ranking
├── Structure
├── TagFeed
├── Timeline
├── Trend
...
大きな機能ごとに namespace を切り、その下にコンポーネントを定義しています。その各コンポーネントをスタイルガイドで一覧できるようにしています。pages ではその各コンポーネントをレイアウトしています。そして utilities は汎用クラス。
2017年の Qiita は上記のような構成で CSS を書いてきました。実装についても Qiita の新記事ページのレイアウト実装 に書いたような比較的チャレンジングなことをしているので、合わせて読んでみて下さい。
また、JavaScript ではもっとチャレンジングなことをしているので、こちらもおすすめ :)
新QiitaでReactをやめてhyperapp採用した背景 - Qiita
-
ECSS については次の連載記事がおすすめです。抽象化を避けるCSS設計方法論「Enduring CSS」 | HTML5Experts.jp ↩