CSS STATSが話題になったからでしょうか、自社のCSSの構成を分析して、記述方針について紹介するポストが続いています。

1) Lonely Planet

Lonely Planetは旅行サイトらしく、写真/動画満載の構成です。

Quick Facts

• Sass Indented Syntax
• 150+ソースファイル
• キャッシュを考慮してコンパイルしたCSSは二つのスタイルシートに
• CSSはページ当たり35kb (gzip)
• 基本的には、remとpixelでサイズ指定。一部 em あり。

Preprocessor

• Railsを使っているが、Sprocketsは利用せずに、Saasの@import機能でスタイルシートをつくっている。
• Saasの機能は variable と一部で mixin くらい。
• classよりplaceholderをextendするアーキテクチャを好んで使っていたが、コードがかなり複雑になる結果となり、OOCSS的アプローチに戻った。
• CSSを解析してvendor prefixを付加してくれる Autoprefixer はお薦め。
• Compassやその他のプラグインは使ってない。

Architecture

• コンポーネント間をうまく区分けして、スタイルの不整合を防ぐために、BEMに沿ったスタイルで開発。
• OOCSSはざっくり。厳密に従ってはいない。
• CSSでIDは使わない。class以外を使うことはほぼない。
• normalize.css
• スタイル要素は避け、書体はclassで規定。うちのデザインにおいてはオーバーライドが頻発するので、書体要素はデフォルトでマージンをとらない。

Frameworks

• CSSフレームワークは使っていない。
• 究極的には依存関係がまったくなく、完全にCSSをコントロールできるようにしたいが、もしフレームワークを使うのであれば、Inuit.css などは検討したい。

Linting

Lintツールは使ってないが、使ってみるべきだと思ってる。

Bundles

• CSSファイルは、core.css と application.css に分けている。
• application.cssは特定のアプリだけ、core.cssはlonelyplanet.com全体でキャッシュされている。10個以上のアプリで構成されたサイトなので、スピーディなレンダリングを実現するために、この仕組みは必須。
• core.cssには、fontやgridなどの基本スタイル、header/footer、各アプリで共通で必要と思われるコンポーネント群が含まれ、オープンソースで公開している Rizzo で管理している。
• application.cssは各アプリ専用のスタイルと、Rizzoのコンポーネントだが core.cssに置くほど使用頻度が高くないものがある。

Performance

• Rizzoのパフォーマンスモニタリング機能を使っている（サンプル画面）。最近導入したばかりなので、時系列での比較はまだ過去7日ベースになっている。
• 数時間ごとに簡単なスクリプトを実行し、スタイルシートを分析。StyleStatsの詳細データも、Rizzoにもってきている（サンプル画面）。

Documentation

• 以前ブログで紹介した、スタイルガイド駆動開発に従っている。
• Sassファイルを[doc]..[/doc]タグで囲み、ドキュメントの生成をしている。例えば、この utility_classes.sassで、このドキュメントがRizzoにできる。

Refactoring

コードは極力減らすという方針。何かのときのために残しておくことはしない。リファクタリングをタスクとして定めてはいないが、日常業務の中で必須と考えている。

Other CSS Files

SVGアイコンとフォントは、CSSファイル内にあるが、後でで読込まれるようになっているので、残りのスタイルとグループ化はされていない。

2) GitHub

Quick facts

• SCSS
• 100+のソースファイル。本番アップ前にコンパイル。
• IE<10のselector数の上限を回避するために、二つのスタイルシートにわけている。合計90kb程度。
• 特定のアーキテクチャは採用していない。
• サイズ指定はpixel単位。一部 em の箇所はあり。
• normalize.cssを使っており、独自のリセットスタイルあり。

Preprocessor

• SCSSはRailsのアセットパイプラインと一部Sprocketsでコンパイル。
• 比較的少ないvariable (フォントやブランドカラー)やmixin（ほとんどはvendor prefixのプロパティ）で構成されているので、コードを早く簡単に書ける。
• Autoprefixerは使ってないが、使うべきだと思っている。
• source mapは近々使いはじめる予定。Inspector内で特定のスタイルが、コンパイル & 縮小化されたスタイルシートではなく、どのソースSCSSファイルからきているか確認できる。
• SCSSの機能は最小限の利用に止め、シンプルに書けるようにしている。color varibale / mixin / color function / math function / nest など。classを繰り返したり、グローバルオプションをセットしたりはしない。

Architecture

• BEMとOOCSSに沿っている。OOCSSの利用は厳密ではない。
  • selectorはclassを最優先で使う。  - 不必要なネストはしない。
  • class名にはシングルダッシュを使う。
  • 混乱しない程度に極力短く。

Linting

• Lintは数週間前にはじめたばかり。下記の項目にあたるとCIビルドが失敗するようになっている。
  • CSSにclassがあるが、app/views/テンプレにない。
  • 同じselectorを複数回使っている。
  • ネストの制限、改行ルール、:の後のスペースなど、一般的なルールに違反している。

Two bundles

IEにおけるselectorの上限である4,095個を上回る約7,000個あるので、二つに分割。ちなみに、他サイトでは、

• Bootstrap v3.2.0 は 1,900以下
• Twitterは 8,900以下
• NY Timesは 2,100弱
• SoundCloudは、7,400だったが、最新バージョンでは 1,100以下。

Included via Sprockets

• CSSとJavaScriptは、Sprocketsとrequireでバンドルしている。CSSバンドルは、app/assets/stylesheet内のサブディレクトリで管理。require_directory .と書くと簡単にバンドルできる。
• どのバンドルにも新しくファイルが追加されることがあるが、Sprocketsのロジックでファイルが並ぶので、ファイル名によっては、コンパイルされたCSS内の予想外の箇所に表示されることがある。また、global variableとmixinに自動的にアクセスできないので、必要な場合は都度、明示的にファイルの先頭で@importすることになる。
• 詳細度の管理が大変なので、メンテ性をあげるために、今後は@importを常に明示する方針にした。

Performance

• 二つのバンドルのサイズやselector数などのメトリックスを取得している。
• Twitterに勤務してた当時は、最初のtweetまでの時間を短くするために関連するスタイルを集めたcoreと、それ以外のmoreに分かれていた。GitHubのバンドルの分割は今のところ任意だが、将来的には何らかの目的をもった分け方がよいと思う。
• selectorのパフォーマンスは実はほとんど懸念していない。必要以上のネストとかIDの使用とか、避けるべきノウハウは認識しているが、過度な最適化はしていない。唯一、diffのレンダリングのためにマークアップを多用するが、[class="octicon"]などを使いすぎるとブラウザがクラッシュするので気をつけている。

Documentation

まだ自慢できるほどではないが、改善はしてきている。スタイルガイドは公表しており、スタイルガイドジェネレータであるKSSを使っている。

Primer

社内共通のスタイルやコンポーネントは、Primeというフレームワークにまとまっている。

• normalization
• box-sizing, フォント、リンクなどのグローバルスタイル
• navigation
• フォーム
• gridシステム
• マークダウンのスタイル
• カスタムセレクトメニュー

Refactoring

気づいたベースで都度積極的に対応している。不要なコードを減らすには、

• 似たようなことを異なるHTMLとCSSでやってるのを見つけたら、まとめる。
• CSSのclassをgrepして、viewと被っていないかチェック。

#css #github #lonelyplanet