• PostCSS とは何か // Speaker Deck

PostCSSとはなにか？

PostCSSは、Autoprefixerの作者でも有名なロシアのAndrey Sitnik氏が開発しているツールです。

• postcss/postcss

公式のレポジトリのREADMEには以下のように書かれています。

PostCSS is a tool for transforming styles with JS plugins. These plugins can support variables and mixins, transpile future CSS syntax, inline images, and more.

PostCSSはCSSのスタイルを変更するためのツールと言えますが、実際に、どのスタイルを変更するかは各種プラグインによって行われます。

PostCSS自体はCSSパーサーでそれによって生成されるAST(抽象構文木、Abstract Syntax Tree)を扱うAPIを提供しているにすぎません。

PostCSSの使用例

例えば、postcss-sizeというプラグインを使えば、独自ショートカットプロパティであるsizeが以下のように使用可能になります。

/* 変換前のCSS */
.rectangle {
	size: 400px 200px;
}
.square {
	size: 250px;
}

/* 変換後のCSS */
.rectangle {
	width: 400px;
	height: 200px;
}
.square {
	width: 250px;
	height: 250px;
}

プラグインを使うことで、sizeプロパティが現状のブラウザでも解釈できるwidthとheightプロパティのCSSに置き換わったのが確認できます。

では、実際にGulpでPostCSSとそのプラグインを使用するにはどうしたらよいのか、見ていきましょう。

var gulp = require('gulp');
var postcss = require('gulp-postcss');

gulp.task('css', function () {
  return gulp.src('src/css/*.css')
    .pipe(postcss([ require('postcss-size') ])
    .pipe(gulp.dest('dest/css'));
});

簡単ですね。postcssの引数の配列に使いたいプラグインを指定するだけです。gulp cssとコマンドを打てば、先ほどのCSSが生成されるようになります。

AutoprefixerもまたPostCSSのプラグインの一種なので、これを先ほどのタスクに追加したのが下記のコードです。Autoprefixerのオプションの設定にlast 2 versionsを設定していますが、基本的には配列の中にプラグインを足していくだけです。

gulp.task('css', function () {
  return gulp.src('src/css/*.css')
    .pipe(postcss([
			require('postcss-size'), 
			require('autoprefixer')({ browsers: ['last 2 versions'] })
		])
    .pipe(gulp.dest('dest/css'));
});

今回はGulpでのタスク実行例でしたが、もちろんGruntなどの他のビルドツールにもPostCSSは対応していますので、みなさんの好きなビルドツールを使うことができます。

PostCSSのプラグインはおおまかに分類すると以下のようなカテゴリーのものがあり、現在100種類以上のプラグインが存在します。

• Future CSS syntax 新しいCSS構文が使えます
• Fallbacks　未対応のブラウザでもその効果を再現します
• Language extensions　for文やif文などの言語拡張します
• Optimizations　ミニファイなどの最適化をします
• Shortcuts　便利なショートカットです
• Analytics　StyleStatsのような分析をします

cssnextでFuture CSS syntaxを先取る！

前述の通り、PostCSSには便利なプラグインがたくさんあり、フロントエンド開発の助けとなることでしょう。しかし、そういったことは既にSassでもできていることなので、メリットとは感じることも少ないかもしれません。個人的にPostCSSを使う一番の意味としてはFuture CSS syntaxを先取ることが可能であるということです。

例えば、CSSで変数を使いたい場合、Sassでは$記号を使い宣言しますが、言うまでもなくこれはSassによる独自構文であり、CSSの標準構文でありません。

/* 変換前のSass */
$brand-color: #88E18E;

.logo {
	color: $brand-color;
}

/* 変換後のCSS */
.logo {
	color: #88E18E;
}

W3CのCSS Custom Properties for Cascading Variables Moduleに対応した現在の書き方だと以下のようになります。

/* 変換前のCSS */
:root {
	--brand-color: #88E18E;
}

.logo {
	color: var(--brand-color)
}

そして、このCSSはpostcss-custom-propertiesプラグインを使えば、Sass同様、通常のCSS 2.1に対応したコードに変換することができます。

このような、新しい標準仕様CSSを使うことができるPostCSSプラグインをまとめたパッケージがcssnextです。これを使えば、postcss-custom-properties、postcss-custom-selectors…のように、いちいち一つひとつプラグインを読み込まなくても大丈夫になります。

• cssnext – Use tomorrow’s CSS syntax, today.

cssnextが内包しているFuture CSS syntaxプラグイン一覧

• custom properties & var()
• custom media queries
• custom selectors
• color() support
• hwb() support
• rebeccapurple
• :not` pseudo-class (to l.3)
• filters (svg fallback)
• ::pseudo syntax (: compat)
• reduced calc()
• media queries ranges
• automatic vendor prefixes
• gray() support
• hexa #rrggbbaa support
• :matches pseudo-class
• font-variant (to font-feature-settings)
• rem units fallback (to px)

上記のパッケージを使えば、JavaScriptにおけるBabelのような使い方がCSSにおいても可能です。

ただ、今年策定されたECMAScript 6のように仕様が固まっているものが少なく、標準に沿った記述をしていても未来の仕様変更に伴い、コードを変更しなければならないといったリスクも存在します。

• The Trouble With Preprocessing Based on Future Specs | CSS-Tricks

この点については、cssnextの作者であるMaxime Thirouin氏はcssnextはsemverを遵守しているので、プラグインをアップデートしたらコードが使えなくなるといったことは防げるとも述べています（互換性がない変更はメジャーアップデートするので、マイナーアップデートで止めれば危険性はないです。semverに関しては以前に取り上げたので次の記事を参照してください）。

• t32k、怒られる！セマンティック バージョニングしてますか？ | HTML5Experts.jp

なにはともあれ、個人的にはSassばかりに目を向けていた昨今なので、CSSの標準仕様に目を向けるという面でも、このようなプラグインを使うことに意味はあるかと考えます。さすがに、cssnextのパッケージに入っているプラグインの仕様すべて追いかけるのは厳しいので、自分が本当に使いたいFuture Specプラグインだけ選んで、それだけ気にかけるというのが落としどころかと思います。

PostCSSの普及

自分にとって必要なプラグインだけ選んで使えるPostCSSの使い勝手の良さから、利用者は増えています。『Sass and Compass for Designers』の著者であるBen Frain氏がSassからPostCSSに乗り換えたという記事は話題になりました。

• Breaking up with Sass: it’s not you, it’s me – Ben Frain

また、フロントエンド開発者のためのコード共有サイトCodePenにおいても、SassやLessなどの他のCSSプリプロセッサ同様に、PostCSSをサポートするようになりました。

世界で最も使われているであろうCSSフレームワークBootstrapが、Version 4においてLessからSassに移行したと最近話題になりましたが、Version 5においては、さらにSassからPost CSSに移行するであろうと作者のMark Otto氏がTweetしたのも興味深いです。

Sassから乗り換えるべきか？

さて、これまでSass、Less、Stylusと群雄割拠のCSSプリプロセッサ時代において、ようやくSassで落ち着きそうなところに、また新しい技術が出てきて困惑しているあなた！大丈夫、僕もそうです！

PostCSSでできることはたいていSassでもできる（ないものはRubyで拡張しなければなりませんが…）ので、機能面で乗り換えるメリットというのはあまりないかもしれません。ただ、パフォーマンス面ではRuby Sassを使っている方ではあれば、少し考慮したほうがよいかもしれません。圧倒的にコンパイル速度が違います。

• 『PostCSS とは何か』より

ただ2007年頃から開発されているSassは仕様的に安定していますし、コミュニティも成熟していますから、あなたの開発プロジェクトに新メンバーが入ってきてもSassであれば問題なく受け入れることがあっても、PostCSSで書かれたコードにはすこし驚く可能性があるでしょう（PreCSSというパッケージを使えば、PostCSSをのプラグインを使用しSassと似たようなコードを記述可能です）。

• Why I’m Not Breaking Up with Sass | James Steinbach

各自のプロジェクトに合わせて、技術を選択していけばよいでしょう。個人的には自分が1人でやっているプロジェクトであれば最近はPostCSSを採用しています。そもそも、Sassの機能においても@extendや@mixinといったこともあまり使いませんし、Too muchな面は否めません。自分としては変数(postcss-custom-properties)と@importによるconcat(postcss-import)さえあれば問題ないといった印象だからです。

Webは常に進化し続けているものなので、それを構成しているコードも変わってくるのは当然でしょう。この際にPostCSSで最新仕様を先取ることで、未来のCSSについていろいろ考えるキッカケにしてもらえば幸いです。

この記事は2015年5月28日に行われたGoogle I/O 2015「Material Now」セッションの翻訳です。「Material Now」では、Material Designがリリースされてからの1年間の状況や反響、事例等を取り上げています。本翻訳の後編は、Google社のデザインに対する取り組みと、Material Designの採用事例について記述します。

Design Sprints

• Design Sprint | Google Developers

私たちはみなさんにMaterialをもっと好きになってもらいたいですし、みなさんのフィードバックをMaterialに取り込みたいと考えています。みなさんと対話するために、去年から私たちはいくつかのプログラムを始めています。

スターターのために、私たちはGoogleでDesign Sprintsを行いました。マウンテンビューのキャンパスでガレージと呼ばれる場所で、1日かけてデザインワークショップをします。いくつかの企業を招いて、そのチームのデザイナー、プログラムマネージャー、エンジニアが一緒にプロダクト開発における特定の問題に取り組むのです。

私たちはそれをサポートするのですが、それはなにも既存のアプリのMaterial Design化だけでなく、アプリデザインをいろんな観点からサポートするのです。これはとても素敵な取り組みで、私たちはみなさんが抱えている問題が何なのかを理解することができます。とても真剣で濃密なプロセスですが、反応はとても良いものでした。私たちは17の企業と協力し、今もこれ続けています。

加えて、私たちは100以上のデザインレビュー、それは1、2時間の短いセッションで、私たちのデザイナーの何人かがみなさんのデザインチームとMaterial Designの実装について話し合うのです。これもまたみなさんと協力しあえることができ、技術・デザイン両面からみなさんをサポートすることができます。

I/Oではデザインのセッションが他にもありますので、ぜひとも、みなさんチェックしてみてください。もし、このようなデザインレビューができないのなら、どうかdesign@google.comまで連絡ください。

FORM

• FORM

昨年、Googleで初めてデザインカンファレンスを、ここサンフランシスコで開催しました。このイベントはとても素晴らしいものとなりました。このイベントは招待制なので、みなさんの中でどれだけの人がこのイベントに行けるかどうかは私にはわかりませんが、デザインコミュニティに繋がっていればその機会があることでしょうし、私たちは世界中のデザイナーを招き、講演をし、パネルディスカッションをし、ハンズオンのワークショップもしました。次のFORMを企画していますので、どうぞご期待ください。

Material Design in the Wild

さて、Material Designについてはここで終わりです。なぜなら、私たちはみなさんにもっと美しいアプリを作ってほしいですし、もっと直感的な体験をみなさんのユーザー・顧客に届けてほしいと考えています。

ここでセッションを終えますが、みなさんが実装したMaterialの事例について話す時間を設けることにしましょう。私たちはいくつかのMaterial Designを採用しようとする企業と話す機会を得ました。そして彼のストーリーを聞きました。そこで彼らの事例についてシェアしたいと思います。

Trello

まず、Trelloです。いくつかのプロジェクトを組織したりシェアするのに便利です。MobileリードのHamidはTrelloのMaterial Design化することで、プロダクトそれ自体、デザインにフォーカスすることができたと言っています。さらにははっきりとしたインパクトも数字として現れています。

• 週間ユーザーあたりのセッション数が10%増加
• セッションあたりのボード作成数が42%増加
• セッションあたりのボードを追加するユーザー数が63%増加

The Hunt

次にファッションスタイルを共有するThe Huntですが、プロダクトデザイナーのJennyは、Material Designはデザインチームをスムーズに拡張してくれるものであり非常に助かっており、それはまたチームを加速させるものだと述べています。私たちは非常に嬉しかったです。なぜならこれは私たちが望んでいたことだからです。同様に、HuntのMaterial Design化で、以前と比べて”Hunts”が30%増加しました。

Pocket Casts

最後に、ポッドキャストアプリのPocket Castsですが、前述のアプリと同じような効果をあげていますし、Material Design化により30%も売上が増加しました。ファンタスティックですね！

このような事例は、なぜMaterialを採用するのかといった証明になりますし、まさしく私たちが進むべきものです。私たちは、みなさんが現在やっていることをさらに集中・加速させることを手助けしようとしているのです。もし、Material Design化に対して説得を要するのならこれらの事例をぜひとも使ってもらいたいです。

みなさんのこのような素晴らしい成果に私たちは非常に感動しました。もう少しこのようなアプリに対してより多くのみなさんにシェアや賞賛をしてもらいたいと考え、私たちPlayチームとDevチームは18の素晴らしいMaterial Designアプリを選択し、ショーケースとしてみなさんにシェアしたいと思います。

• Best-In-Class Android Design – Google Play の Android アプリ

昨年、Material Designを紹介する動画を作成しましたが、実際それらはフェイクのアプリですが、今回並んでいるのは実際のみなさんが作ったまぎれもないリアルなアプリです。私たちは非常に興奮しております。

Material Design Award

• Material Design Awards – Articles – Google Design

さらに私たちは、特定の分野でもっとも素晴らしいMaterial Designをしているアプリを表彰するためのMaterial Design Awardも用意しました。今年は6つのカテゴリーから選びました。これらのアプリはまさしくMaterial Designのパイオニアです。

• Adaptive Layouts – Pocket
• Immersive Imagery – B&H Photo Video Pro Audio
• Elegant Typography – NYTimes – Latest News
• Seamless Browsing – Pocket Casts
• Crafted Simplicity – Weather Timeline – Forecast
• Delightful Animation – Tumblr

私たちMaterial Designチーム全体は非常にみなさんに感謝いたしております。なぜなら、システムそれ自体はただのアイデアに過ぎませんが、みなさんの日々の仕事のがんばり、貢献、革新のおかげで、Material Designがリアルなものとして、実際に手に触れるものとなったのです。本当にありがとうございます。

そういうわけで、Material Designの最初の一年は素晴らしくわくわくするような成功した一年でした。私たちは引き続き、みなさんとコミュニケーションしていきたいと考えています。何が機能して、何が機能しないのか、などみなさんから学びたい。次の一年はさらに素晴らしい一年となることを楽しみにしていますし、また来年ここGoogle I/OでMaterial Designの2歳の誕生日を祝うために集まりましょう。今日は本当にありがとうございました。

この記事は2015年5月28日に行われたGoogle I/O 2015「Material Now」セッションの翻訳です。「Material Now」では、Material Designがリリースされてからの1年間の状況や反響、事例等を取り上げています。本翻訳の前編は、Material Designの普及状況とアップデート内容について記述します。

• Material Now – Google I/O 2015

こんにちは、みなさん。私の名前はMatias Duarteです。今日はMaterial Nowについてお話したいと思います。まずは、ハッピーバースデー！Materialですね。記念すべきマイルストーンです。昨年のI/Oで私たちはMaterial Designを紹介しました。私たちは異なるプラットフォーム、異なるスクリーンサイズを超えたデザインシステムを作りたかったのです。私たちはモダンなグラフィックデザインと現実的なユーティリティ、ユーザービリティを組み合わせたかったのです。そして、後づけではないモーションデザインを重視したシステムを作りたかったのです。

信じられないかもしれませんが、私たちがMaterial Designを作っていた時、どのようにそれが受け入れられるのか、少しナーバスでした。しかし、ふたを開けてみれば、私たちはそれを気に入っていましたし、こんな素敵なクオートも見かけました。

Material Designは単なるタブレット・スマートフォン用のデザインではない。それはプロダクトが何百万というユーザーにどうコミュニケーションするのかシステマティックなアプローチである。
— Gizmodo

また開発者のみなさんも、良い反応を示してくれました。

Googleはデザインゲームを次に進めた。それは絶対的な美的感覚に頼る変わりに、個々のデザイナーをより自由にする原則を定義したのだ。
— Sacha Greif Creator of Folyo, Telescope, and Sidebar

もちろん、デザイナーのみなさんもMaterial Designが何を解決しようとしているのか、そのシステムが、すべてのインタラクティブなプラットフォーム上でデザインする上で助けになると、とても理解しているよう思えます。

Material Designは、Web全体のビジュアルを根本的に変えるポテンシャルを持っている。
— Armin Vit Under Consideration/Brand New

こういった感想を聞けて、私たちはホッとしました。しかし、本当にみなさんが聞きたいのは、どのくらいMaterialが役に立っているのか？ということでしょう。私たちGoogleは数字が好きですので、ここでMaterial Designに関する数字を見ていきましょう。

Material Designに関するデータ

まずは、私たちのMaterial Designガイドラインを見ていきましょう。私たちはこれを親しみを込めて、『スペック』と呼んでいます。この一年足らずで、250万ユニークビジターがこのスペックに訪れました。これはとても良い結果だと私は考えます。もし、あなたがYoutuberであったり猫動画をアップロードしている人であれば、これはそんなに良い結果とは言えないでしょう。しかし、これはデザインガイドラインですよ？すごくありませんか？

もっと重要なことに、このうち60%以上のユーザーが再訪問しているのです。これはMaterial Designガイドライン決して一度チラ見すれば理解できるものではないですし、何度も何度も見るような役立つリファレンスだということでしょう。特に、カラー、タイポグラフィとアイコン、そしてもちろん、FAB（Floating Action Button）などのコンポーネントのセクションが特に閲覧されているようです。

デザイナーだけでなく、開発者のみなさんもMaterialを使っています。Polymerに目を向ければ、MaterialコンポーネントをWebに実装するために必要なシステム、Paper Elementの仕様書が250万回も閲覧されています。もっと重要なことは、10万ものWebプロジェクトで、このフレームワークが使われていることです。

また、みなさんが気にかけているのはAndroid上ではどのくらいなのか？でしょう。Play Store上では25万近くのMaterial Designを実装したアプリを確認することができます。たぶん、これはそんなに大きな数字ではないでしょう。なぜなら何十億というAndroidデバイスがあるというのに、もしくはPlay Storeができてからの7年間どれだけのアプリがリリースされたのだろうか？と考えるからです。

違う観点からこの数字を見れば、2014年10月にLollipop(Android 5.0)がリリースされてから、Play Storeで出されたアプリの40％はMaterial Designを採用しています。これは良い結果だと考えています。新しくできたアプリの3つに1つはMaterialの恩恵を受けているからです。

これらは始まりにしかすぎませんが、私たちはもっとこの数字を大きくしたいと考えています。デザインに終わりはありません。そこでこれらの数字をどのように大きくするのか、またいかに早く普及させるのか、そしてMaterialをみなさんにいかに簡単に使ってもらうか説明したいと思います。

私たちは、より良く、より包括的にするためにMaterial Designガイドラインのアップデートを公開以来、続けています。実際、私たちはこれまで2回アップデートを既にしています。

最初は2014年11月、Organizing Objects、Navigation Drawers、スクローリングテクニック、Swipe to Reflesh、プロダクトアイコンのセクションを追加しました。

2015年4月のアップデートでは、Data Tables、App StructureなどのMaterial Designのガイドラインを多く追記しました。

2015年5月のアップデート

そして今日、2015年5月はガイドライン公開後もっとも大きなアップデートとなります。非常に多くのものを追加しました。その中にはデザインパターンのリニューアルも含まれています。

Floating Action Button

そう、みなさんも好きなFABです。スペック公開時は非常に限定したガイドラインになっており、どのようにフローティングアクションボタンが振る舞うのか、もっと違うトランスフォームがあるのではないか、もっと柔軟性があっては良いのではないかとみなさん考えたことでしょう。私たちもそう思います。よって今日はこのFABパターンを拡張したいと思います。これによりもっと柔軟にFABをみなさんのアプリに実装することができることでしょう。

Material Icon Library

また、今日はスペックにまったく新しいリソース、Material Iconライブラリを追加しました。このサイトには750以上ものみなさんのプロジェクトで簡単に使えるアイコンあります。しかも、ワンクリックでプロジェクトに導入できるようにしてあります。アプリ開発者のみなさんはすべての必要な解像度のアイコンをここでダウンロードできます。さらにこれらのアイコンをWebフォントとしてもリリースしてますので、リガチャ（合字）として利用できるので、みなさんはアイコンの名前をタイプするだけで実装できます。とってもクールですよね？

Adaptive Layout

• Adaptive UI – Layout – Google design guidelines

Material Designについての要望で一番大きなものと１つとしてアダプティブレイアウトがあります。このため、今回はスケーラブルで一貫性のあるグリッド、レイアウト間でのブレークポイント、振る舞いなど関する詳細なセクションを新たに追加しました。この新しいパターンはきっとどのコンテキストにもなじむことでしょう。

Device Metrics

• Device Metrics – Google Design

加えて、アダプティブデザインのためにデバイスのサイズレファレンスを新たにサイトに追加しました。これは、ウェアラブルだろうと、携帯端末であろうとも、タブレット・ラップトップであろうとも任意のサイズのデバイス上でデザインするときに役立つでしょう。そしてキーとなる解像度や密度を発見できるでしょう。もっと重要なことは、これによってどのデバイス・向きで、どのアダプティブテンプレート・パターンを使うべきか理解できるようになったことでしょう。この2つのリソースがみなさんの役に立つことを祈っています。

もちろん、ほかにもたくさんのアップデートがあります。意味のあるモーションについて解説したセクション、ローンチスクリーン、エンプティステートなどの追加と、多くのアップデートがなされました。

そして、現在Material Designはほかのプロダクト、TV、Auto、VRのCardboardに対しても適用できるよう、ガイドラインを追加しました。

今回の大型アップデートによって、みなさんのデザインのお役に立てること祈っていますし、私たちに引き続きフィードバックをください。そうすれば、私たちはアップデートを続けることができます。

私たちはガイドライン・ツール、リファレンスの枠を超えたかったのです。つまり、それらはいくぶんか静的で、ドライ、権威的なのです。そこで、私たちはデザイナーがダイレクトに繋がれる場所にするために、Google Designを新しくリニューアルしました。

つまり、それをデザイナーと開発者のコミュニティにしたかったのです。どうしてデザインをするのか、どのようにデザインするのかといった情報をシェアする場所として考えています。実用的な記事やビデオを配信することで、デザイナー・開発者が抱えている関心事、例えば、どのようにブランド・アイデンティティを損なわずMaterial Designを実装するのかなどを解決できると思っています。

また、Android、iOS、Webと異なるプラットフォーム間でデザインを簡単にするTipsなどの記事などもあります。私たちはみなさんにどこでも快適にMaterialを使ってほしいと思っています。チュートリアルもちろん、Material Designの裏側のシーンを収めたビデオなどもありますので、どうぞチェックしてみてください。

Polymer

• Welcome – Polymer

ここまで紹介してきた技術はデザイナーにとって、Materialを表現する上で便利なものですが、今日は開発者のカンファレンスですからMaterialを実装する上で役立つものを紹介したいと思います。

もちろん、最初はPolymerです。今日Polymer 1.0がアナウンスされました。これはパフォーマンス的にも満足が得られるようになったり、安定したり、APIが固定されたことを意味します。PolymerはモダンなWebプラットフォームとモバイルプラットフォームのために必要なものです。もしPolymerを使えば、簡単にスケール可能なアプリケーションを作ることができるでしょう。Polymer開発チームはパフォーマンス改善のために、一行毎にPolymerのコードを書き直したと私に言いました。とっても速くなりましたよ。つまり、プロダクション用途に使ってもらっても問題ないということであり、高品質のアプリのようなものをWeb上でも作成可能ということです。

さらに、Polymer Starter kitとCatalogはMaterial Designのアプリ作成にとりかかる前に、すべてのPaper Elementsを実際に使って試してみることができます。デモやサンプルも含んでいて、とっても見やすいサイトになっていますし、コマンドラインを使わなくてもクールなショッピングカートで各エレメンツをダウンロードできます。

Android Design Library

もちろん、MaterialはAndroid 5.0、Mでも使うことができますが、みなさんは2つの気にかかっていることでしょう。もっと簡単に使いやすいコンポーネントがないのか、そして後方互換性も広く対応してほしいと。

Support Libraryは常に後方互換性と対峙しています。これはプラグ・アンド・プレイシステムなので、古いAndroidバージョンで新しい機能を動かすことができます。昨年、Materialをリリースしたとき、appcompat libraryを提供しました。これは基本的なレイアウトとスタイリングをサポートするライブラリです。

今回紹介する新しいライブラリはAndroid Design Libraryです。このライブラリはMaterial Designのコアエレメントを使うことができ、隠蔽化された実装を簡単に導入することもできます。例えば、以前シンプルなFABを実装するにも5,6つのXMLファイルが必要でしたが、今日からは1つのフローティングアクションボタンの要素を追加するだけです。新しいライブラリは、他にも簡単に実装できるシャドウ付きのカード、複雑なサイドナビゲーションも、Navigation Drawer Viewにドロップするだけで、スペック通りの動作をするコンポーネントを実装できます。

同様にMaterialタブもまた、アプリに簡単に実装できます。私のお気に入りであり、複雑なコンポーネントで知られるツールバースクローリングも１つのコンポーネントにピンチなどの動作を設定するだけで実装できます。パレットは去年紹介しましたが、今日はそれが6倍速くなりました。詳細について知りたければデベロッパーサイトを確認して下さい。

先ほど、私はSupport libraryは完全なMaterialコンポーネントを提供していない、つまり簡単にデプロイできない、より多くのAndroidデバイスに提供できていないと申し上げました。現在、LoliipopはAndroidデバイスの10%程度しかありませんが、今回紹介した新しいSupport libraryを使用すれば、Android2.1以上のデバイスにMaterialを提供することができます。最高じゃありませんか？

（後編に続きます）

本記事は、2015年2月21日に行われたFrontrend Conferenceの「Evaluating CSS」の内容を紹介します。

はじめに

こんにちは、@t32kです。今日はEvaluating CSSというタイトルでCSSの解析ツール、StyleStatsに関して説明したいと思います。ちなみにEvaluateというのは『評価する、価値を見極める』といった意味の単語です。

宣伝ですが、今年からFrontend Weeklyという無料のメールマガジンというか、海外の役立つリソースを紹介するウィークリーメールをやってますので、こちらも登録いただけると大変私嬉しいです。

なぜCSSはそんなに難しいのか？

では、まずなぜCSSはこんなに難しいのか考えてみましょう？いやいや、CSSってすごく、すごく単純ですよね。

こういったひとつのRuleがあります。divとsectionというSelectorがあります。その中にDeclarationをしていきます。DeclarationはPropertyとValueから成り立っています。

どうですか、これだけ見るには、すごく簡単ですよね。これのどこが難しいのでしょうか？ちょっと冷静に考えてみてください。ただ単純にCSSを書き連ねていくのは、誰でもできます。しかし、それのメンテンナンス性を維持しつつ、スケーラブル性も保ちながら管理していくのは非常に難しいです。

なぜならCSSにはスコープもなければ、抽象化する術も持たないので、どうしても冗長に書かざるを得なくなってしまいますし、現状はセレクタの命名規則でなんとかまかなうしかないのです。

JavaScriptサイドはよいですね。ES6などでどんどんと強力な機能が追加されていっています。しかし、CSSはプロパティは増えれども構造的にはなにも進化してません。SassなどのCSSプリプロセッサーなどは登場してきてますが、結局コンパイルしてしまえば、ただのCSSです。CSSには頑張ってほしいところです。

CSSサイズファイルの増加

CSSは冗長的にしか書けませんので、時と共にじわじわと増加していきます。上記のグラフは、私が制作していたWebアプリケーションのデプロイ毎にCSSファイルサイズを記録しています。2回ほど大きく減少していますが、これは私が不慣れな書き方をしていたのをリファクタリングした結果でして、そのようなコードがなくなれば、あとはじわじわとファイルサイズが増加していくだけです。

私はこれが非常に怖い問題だと思っています。例えば、CSSのせいでレイアウトが崩れた！といったバグなどありますが、そういったものは探せば原因が見つかってすぐに直せます。たいした問題ではありません。しかし、このようにゆっくりとファイルサイズが増加していく場合は、それが問題だと認識しづらいという点が問題です。

クリティカルレンダリングパスの観点から言えば、CSSファイルサイズがダウンロード・パースされるまでレンダリングはブロックされます。つまり、レンダリング遅延の問題が懸念されます。では表示遅延が問題（体感できるように）になってから、解決にリファクタリングしようとしても、スパゲッティ化したコードを一体どこから手を付けていいのかわからない状況に陥ります。

デザインに依存

また、CSSはデザインに大きく依存します。いくらあなたがスーパーCSSハッカーであろうとも、どうしようもないデザインをベースにコーディングすれば、どうしようもないスタイルシートができ上がります。

Contents(HTML)、Presentation(CSS)、Behavior(JavaScript)といったWebデザインの3つのレイヤーがありますが、結局、HTML/CSSコーディングというのはビジュアルデザイン（PSD）から、ContentsとPresentationを分離させる作業ともいえます。

イレギュラーなデザインパターンを、CSS側で吸収するのは限度があります。そのため、最近ではページをデザインするのではなく、システムをデザインする考え方がよいです。つまり、ひとつひとつのコンポーネント（部品）から成り立つCSSであれば、部品を組み合わせることで、CSSの増加させずにさまざまなビジュアルパターンを制作することができます。

そのためには、スタイル（コンポーネント）ガイドのようなものを日常的に管理し、デザイナーとそれを参照しながらデザインをしてもらうといった制作スタイルも考えられます。

CSSエンジニアになる

しかしデザインもまた、突発的なデザイン変更やクライアントの希望などで、一貫性を保つことが難しい場合もあります。それを『デザイナーの責任だー！』と言っていれば、私たちはただのコーダーで終わるしかありません。私たち側でもよりよいものを作るために努力しなければなりません。

個人的にはエンジニアとはそういう存在だと思っています。だから私はCSSエンジニアになりたいと思いました。

エンジニアとは、主に工学（エンジニアリング）分野の専門的な技術を持った実践者のことである。

• 技術者 – Wikipedia

エンジニアとは上記のような人のことを言うそうです。さらにソフトウェアエンジニアリングのWikipediaを見てみると、ソフトウェアの開発プロセスというものがありました。

CSSにおける 要求 · 仕様 は、デザイナーが出してくるPSDでしょう。ここに関しては今までどおりデザイナーと対話する必要があります。

アーキテクチャ · 設計 に関しては、HTML5エキスパートである谷さんの『Web制作者のためのCSS設計の教科書』を読めば大丈夫でしょう。

問題は、実装 · テスト と 展開 · 保守 の2つの段階でコレといったモノがないことです。私はこの辺りを解決するモノがほしかったのです。

CSSを評価してみましょう

そういう理由で、私はStyleStatsを作成しました。StyleStatsにスタイルシートに解析させることで、さまざまな指標が得られます。v5.0.1時点で29の指標を確認することができます。基本的な使い方と各種指標の意味は、以前書いた記事を参照してください。

• 自分の書いたコードが即座に解析できる「StyleStats」でCSSを測ろう！ | HTML5Experts.jp

v5.0.0でいろいろコマンドラインのオプション名が変わっていますので、ヘルプでご確認ください。

$ stylestats -h

  Usage: stylestats [options] 

  Options:

    -h, --help             output usage information
    -V, --version          output the version number
    -c, --config [path]    set configurations
    -f, --format [format]  set the output format 
    -t, --template [path]  set the template path for output formant
    -s, --specs [path]     run test with your test specs file
    -n, --number           show only numeral metrics
    -m, --mobile           set the mobile user agent

CSSと十把一絡げにいっても、HTML5エキスパートの谷さんが書くCSSと、新卒エンジニアの書くそれとでは大きく違うことでしょう。しかし、違うフィールドの人が一見してみれば同じように見えるでしょう。そこでStyleStatsに解析させてみれば、数値的に比較できれば違いが分かります。エキスパートの書いたCSSであれば、CSSでバッドプラクティスと思われる指標の数値は低く、ファイルサイズもまた小さいことでしょう。そういったことがStyleStatsでは目視で確認するより圧倒的に速く理解できます。

類似ツール

まずは、CSS DigというChrome拡張機能があります。解析したいページに行き、拡張ボタンを押すだけで解析できます。

次にCSS StatsというWebアプリケーションがあります。Specificity Graphなど、StyleStatsにはない機能もあります。

StyleStatsもCLIだけでなく、GUIとしてのWebアプリケーションが提供されています。

• StyleStats – Useful tool to collect CSS statistics

また、npmモジュールとしてProgrammaticalに利用することもできるため、他にGruntやGulpからも利用することができます。また、解析が終わったらSlackに結果を投稿するなどのインテグレーションも考えられます。

おかげさまで、FT LabsやLonely Planetなどの世界的な企業でStyleStatsは使われております。

結局、私が欲しかったのはエンジニアリングとしてのツールで、それを継続的インテグレーションに組み込みたかったという点があります。

CIプロセスにCSSの評価を組み込めば、CSSを書く人だけでなく、デザイナーやバックエンドのエンジニアも今のCSSの状態が分かるようになります。その中で、StyleStatsでどのようにモニターとテストをすればよいか説明します。

モニター

前述のとおり、CSSは徐々に徐々に増えていきます。気づいたら手遅れになっていた、ということのないように常日頃から監視しておく必要性があります。StyleStatsを使えば、Jenkins上から実行させ、それをグラフとしてプロットすることができます。これは前回の記事でも紹介したとおりです。

また、最近ではFT Labsの方がkaelig/moniteurというモニタリングWebアプリケーションを作成してくれました。git cloneしてきて、ローカルでも動作させることが可能です。Webアプリケーションのとして動かすにはRedisサーバーを使うことになるのですが、そこまで難しくはないので試してみてください。

User Specified Selectors

v5.0.0で追加された新規指標のUser Specified Selectorsは、ユーザー指定のセレクタ数をカウントすることができます。config.jsonで"userSpecifiedSelectors"の値に任意の正規表現を記述することで、指標を表示させることができます。

これにより、例えばBEMでのModifierの数やElementの数などカウントするこもできますし、CSSを記述する人が独自の命名規則（独自の接頭辞を持つクラスセレクタ等）さえ、守っていればいろいろ計測することができます。

テスト

次にテストですが、CSSには古くからCSS Lintがあります。これはさまざまなエディタのプラグインが揃っていたりGrunt/Gulpのプラグインもあるので、多くの人が使われているかと思います。

しかし、これは単純に使ってたらエラーが出るだけのものです。例えば、古くから運用しているサイトのCSSを解析したい場合、昔にIDセレクタを使っていたといったことがあります。そこで、StyleStatsでは5個以上あったらエラーとするなど、任意の値でCSSをテストすることできます。

{
  "defaults": {
    "suiteName": "StyleStats Test Suite for sample.css",
    "text": "{metric}: {actual} should be {operation} {expected}",
    "operation": "<",
    "reporter": "spec"
  },
  "results": {
    "simplicity": {
      "min": 0.4
    },
    "size": 20000,
    "dataUriSize": 8000,
    "idSelectors": 20,
    "importantKeywords": {
      "min": 2,
      "max": 8
    },
    "javascriptSpecificSelectors": 1
  }
}

上記のコードのようにtest-specs.jsonでテストのしきい値を設定します。例えば上記の条件だと、IDセレクタが20個以上だったらエラーでビルドが中止されます。

StyleStatsでテストできる指標は数値的なものであれば何でもできますので、例えば単純にsizeに着目してもいいですし、先ほど説明したUser Specified Selectorsを使って、独自の基準を設けてもらっても大丈夫です。大事なのは皆の前でテストを失敗させる（エラーにならないほうが良いのですが）ことでCSSの問題をプロジェクトチーム全体の問題にすることです。

まとめ

そういうわけで、CSSはいまだにどうしようもないですが、CSSを扱う人間までがどうしようもないわけではありません。CSSの問題は一人で解決できないので、その問題をチームで共有しましょう。

現状のCSSを状態を常に確認し、ある程度のしきい値をあらかじめ決めておく。肥大化してエラーが出る度になぜクリアできないのか皆で話し合う。そうすることによって、CSSを扱う私たちの価値も上がっていくのではないでしょうか。

今日はセマンティック バージョニングについて解説します。自身が公開しているライブラリやパッケージのコードを何かしら修正したら、それに伴いバージョンを上げるのが一般的だと思うのですが、実はどのようにバージョンを上げるのが適切なのか、昔の私は理解していませんでした。

『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』などと、なんとなくにバージョニングをしていました。

t32k、怒られる！

If the plugin’s API changes dramatically (for example, when sortOrder option is renamed to config), there should be a major version update. See http://semver.org./

• Use semantic versioning · Issue #15 · csscomb/grunt-csscomb

そんなときに起こったのが上記の事件です。grunt-csscombという私が管理しているGruntプラグインですが、そのアップデートの際に私がバージョニングを間違えてしまい、同じCSSCombチームのロシアのサンクトペテルブルク在住の青年エンジニアに怒られている悲惨な状況です。

彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。

恥ずかしながら、この時初めてSemantic Versioningなるものを知りました。それよりも30歳も過ぎた大人がですね、地球の裏側ほど離れている、見たこともない青年に怒られている事実に私はへこみましたorz…

セマンティック バージョニングの翻訳

ということで、そのSemantic Versioningなるものを勉強してみました。

• Semantic Versioning 2.0.0

Semantic VersioningはGravatarsの考案者であり、GitHubの共同創設者でもあるTom Preston-Werner氏によって作成されました。去年、Rubyのバージョニングにも導入されて話題になってましたね。

勉強がてら翻訳して、先日プルリクエストがマージされましたので、現在日本語でも閲覧可能です。

• セマンティック バージョニング 2.0.0

2度とですね、僕みたいな悲しいおっさんを増やしたくないので、皆さんもちゃんと読んでOSS活動しましょう。

セマンティック バージョニングの導入

詳細は公式サイトを見てもらえればよいのですが、なにせ長いですので、ざっくり、最低限、以下のことだけ覚えてください。

1. APIの変更に互換性のない場合は、メジャーバージョン上げる
2. 後方互換性があり機能性を追加した場合は、マイナーバージョンを上げる
3. 後方互換性を伴うバグ修正をした場合は、パッチバージョンを上げる

例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります。

一番重要なのはAPIに変更があった場合、メジャーバージョンを変更しなければならないということです。先のgrunt-csscombの件もsortOrderというオプション名をconfigに変更したので、このプラグインを使用しているユーザーはGruntfileを更新しなければならないケースが出てきます。

逆を言えば、セマンティック バージョニングが浸透しているコンテキストにおいては、メジャーバージョンのアップデートだけ気にしていれば、ユーザーは気軽に自身の依存しているパッケージをアップデートできるということです。

複雑なアプリケーションになればなるほど、依存するパッケージも多くなるので、それらをアップデートする際にちゃんと動作するのか、ひとつひとつ気に病むのは大変ですよね。セマンティック バージョニングという共通ルールは、そういった問題を解決するためにあります。

以前までのバージョンに対する私の一般的な印象は、大きければ大きいほど安定しているといったものでした。実際、そういった意味で商業的なバージョニングもあります（大した機能追加もないのに、大げさなバージョン名をつけるなど）。

例えば、Google Chromeは2014年12月現在バージョン39ですが、これはセマンティック バージョニングの観点から言えば、バージョン1.0でパブリックなAPIが定まってから38回もAPIが変更されたということになります（実際は高速リリースサイクルのためですが…）。

そのため、セマンティック バージョニングにとってメジャーバージョンが大きいということは開発者にとっては、APIがコロコロ変わるということであまり好ましくない状況といえるかもしれません。

しかし、気軽に作成・公開したパッケージで、『やっぱりこのメソッド名イケてないわー変えたいわー』といような状況が考えられます。そのような場合、新旧のAPIを両方残し、旧APIをdeprecatedと宣言して、マイナーバージョンを上げるだけに留めたほうがよいでしょう。

実際、私の作っているCSSの指標を計測するパッケージStyleStatsも、比較的軽微なAPIの変更を3回もしたため、あっという間にバージョンが4になってしまった経験があります。その都度、APIの変更がどういったものなのかユーザーに確認させるのは良くないことです。

そうゆうわけで、まとめますと、

• セマンティック バージョニングを守ろう
• リリースノートをちゃんと書こう

です。ありがとございました。

合わせて読みたい

• 意外と知らないバージョン表記・数字の豆知識 – ＠IT

私は仕事では主にHTML/CSSコーディングを担当しているのですが、自分の書いたCSSがイケてるのか、そうでないのか、気になります。私、気になります！そうでなくても、他プロジェクトのCSSのレビューをお願いされたりすることもあるので、そのCSSがどのような状態であるのか、すばやく簡単に理解する必要性がありました。

そこで私は、StyleStatsというNode.js製のツールを作りました。

• t32k/stylestats – GitHub

StyleStatsの使い方はとても簡単です。ターミナルから下記コマンドを打てば、すぐにCSSを解析した結果が得られます。

$ npm install -g stylestats $ stylestats http://t32k.me/static/blog/skelton.css

stylestatsの引数に調べたいCSSファイルのパス（複数ファイル、リモートファイル対応）を入力すれば解析してくれます。

解析結果：

StyleStats! ┌─────────────────────────────────┬──────────────────────┐ │ Stylesheets │ 1 │ ├─────────────────────────────────┼──────────────────────┤ │ Size │ 15.1KB │ ├─────────────────────────────────┼──────────────────────┤ │ Rules │ 207 │ ├─────────────────────────────────┼──────────────────────┤ │ Selectors │ 424 │ ├─────────────────────────────────┼──────────────────────┤ │ Simplicity │ 48.82% │ ├─────────────────────────────────┼──────────────────────┤ │ Most Identifers │ 4 │ ├─────────────────────────────────┼──────────────────────┤ │ Most Identifers Selector │ nav ul li a │ ├─────────────────────────────────┼──────────────────────┤ │ Lowest Cohesion │ 24 │ ├─────────────────────────────────┼──────────────────────┤ │ Lowest Cohesion Selector │ a.button │ ├─────────────────────────────────┼──────────────────────┤ │ Total Unique Font Sizes │ 15 │ ├─────────────────────────────────┼──────────────────────┤ │ Unique Font Size │ 10px │ │ │ 11px │ ├─────────────────────────────────┼──────────────────────┤ │ Total Unique Colors │ 11 │ ├─────────────────────────────────┼──────────────────────┤ │ Unique Color │ #000 │ │ │ #777 │ ├─────────────────────────────────┼──────────────────────┤ │ Id Selectors │ 14 │ ├─────────────────────────────────┼──────────────────────┤ │ Universal Selectors │ 0 │ ├─────────────────────────────────┼──────────────────────┤ │ Unqualified Attribute Selectors │ 7 │ ├─────────────────────────────────┼──────────────────────┤ │ Javascript Specific Selectors │ 0 │ ├─────────────────────────────────┼──────────────────────┤ │ Important Keywords │ 6 │ ├─────────────────────────────────┼──────────────────────┤ │ Float Properties │ 4 │ ├─────────────────────────────────┼──────────────────────┤ │ Media Queries │ 8 │ ├─────────────────────────────────┼──────────────────────┤ │ Properties Count │ width: 53 │ │ │ padding-left: 32 │ └─────────────────────────────────┴──────────────────────┘

なぜCSSを解析する必要があるのか？

単純にCSSを記述することは非常に簡単です。スタイルを当てたいターゲットをセレクタで表現し、そのブロックの中にプロパティと値を宣言していくだけです。

この方法は閲覧するだけのドキュメントをスタイル付けするのには問題はなかったでしょう。しかし、現在、私たちが作っているWebサイトというのは単純に読むだけのドキュメントというよりかは、アプリケーションに近い性質があります。アプリケーションというのはユーザーがしてほしいタスクを実行するもので状態変化などを伴いますし、デスクトップアプリケーションを見れば分かる通り、ボタンのような多種多様なUIコンポーネントを必要とします。また、Webアプリケーションはひっきりなしにリニューアルされ、UIコンポーネントを修正したり、削除したり、追加する必要性があります。

Webアプリケーションを実現するために、従来のドキュメント型のサイトを構築してきたようなCSSの記述の仕方をしていれば、すぐさまCSSはスパゲッティ化することでしょう。そこで私たちは、CSSを書く上でのベストプラクティスを理解しなければなりません。

• Rules · stubbornella/csslint Wiki

基本的にはJSHintのように、CSSにもCSS Lintがあるので、こういったツールを使えばよいと思います。StyleStatsで出力される指標は、CSS Lintで指摘される項目を参考にしたものなので、StyleStatsを実行することで、そのベストプラクティスから自分のコードがどれだけ適応しているのか確認することができます。

CSSは基本的にUIに責任を持っているため、JavaScriptのように致命的なエラーになることが少ないかと思います。しかし、これがやっかいな問題だと思います。なんとなく使っていないコードが残っていたり、なんとなく非効率なセレクターを書いてたりして、問題が顕在化したときに対処しようと思っても、スパゲッティすぎてどうすることもできない（Command+A Delete!）ということがあります。

そうならないためにも、日々のコード品質チェックは欠かせないものと思います。

• es-analysis/plato
• Plato – JavaScript Introspection

JavaScriptにPlatoという解析ツールがあるのですが、ちょうどこれのCSS版となれるよう今後ともStyleStatsを開発していくつもりです。

各種指標の意味

単純にファイルサイズだけを見ていても、そのCSSが良いCSSなのか悪いCSSなのかよく分かりませんので、その他にもCSS Lintをベースとした指標があります。

$ stylestats -c path/to/.stylestatsrc

のように、.stylestatsrcといった設定JSONファイルを一緒に読み込むことで、指標の表示・非表示などカスタマイズできます。

今回解説する指標はv2.2.1時での指標となります。今後、変更や追加などが想定されますので、留意しておいてください。

Stylesheets

stylesheets : boolean

解析するスタイルシートの数。下記のように3つのファイルを解析すれば、この値は3になります。

$ stylestats path/to/foo.css path/to/bar.css path/to/baz.css

Size

"stylesheets": true

解析するスタイルシートのファイルサイズです。複数読み込んだ場合は、合計値となります（以後の指標に関しても同じ）。

Data Uri Size と　Raito Of Data Uri Size

"dataUriSize": true, "raitoOfDataUriSize": true,

スタイルシート内のインライン画像のサイズとスタイルシートに対する割合です。画像をインライン画像にすることでHTTPリクエストを抑えることができますが、外部CSSファイルがダウンロードされないとレンダリングが始まらないので、この数値が大きすぎるのもよくありません。

Gzipped Size

"gzippedSize": false

解析するスタイルシートのgzip後のファイルサイズです。処理が重いのでデフォルトでは、OFF(false)にしてあります。

Rules

"rules": true

ルール（宣言ブロック）の数です（上図参照）。

Selectors

"selectors": true

セレクタの数です（上図参照）。

Simplicity

"simplicity": true

Rules / Selectors をパーセンテージで表したものです。これは個人的に追加した指標なのですが、Sassの@extendなどで継承していると下記のような状態になったりします。もちろんこれはバッドプラクティス的な継承の使い方かと思います。

このようにならないためにも、1つのルールには1つのセレクタが対応しているほうが、シンプルで都合がよいかとおもいます。

Most Identifers と Most Identifers Selector

"mostIdentifers": true,　"mostIdentifersSelector": true

セレクタの中で最も識別子が多いセレクタとその数を表示します。

.foo .bar .baz { color: red; }

上記のセレクタの識別子は、3つとなります。これもSassのネストのような機能を使っていると、深くなる傾向がありますので、気をつけてください。

Lowest Cohesion と Lowest Cohesion Selector

"lowestCohesion": true, "lowestCohesionSelector": true

cohesionは凝集度のことです。凝集度に関してはWikipediaを参照。

凝集度（ぎょうしゅうど、コヒージョン、cohesion）とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。IPAが実施する情報処理技術者試験では、強度(きょうど、ストレングス、strength)という言葉が使われる。凝集度は順序尺度の一種であり、「凝集度が高い」とか「凝集度が低い」といった言い方で使われる。凝集度の高いモジュールは、堅牢性、信頼性、再利用性、読みやすさなどの点で好ましく、凝集度の低いモジュールは保守/評価/再利用/読解が難しいため、好ましくないとされる。

• 凝集度 – Wikipedia

Lowest Cohesionは、SOLID CSSのSingle Responsibility Principle / 単一責任の原則に由来していて、一つのルールにあまりいろいろなスタイルを詰め過ぎないほうがよいです。そこで、Lowest Cohesionは各ルール内で一番宣言数が多いルールのセレクタと宣言数を表します。

Total Unique Font Sizes と Unique Font Size

"totalUniqueFontSizes": true, "uniqueFontSize": true

ユニークなフォントサイズとその数です。現状、font-sizeプロパティで宣言されている値をとっています。fontプロパティによるショートカットで宣言されている値を取得できていません。

Total Unique Colors と Unique Color

"totalUniqueColors": true, "uniqueColor": true

ユニークなカラーとその数です、現状、colorプロパティで宣言されている値を取得しています。background-color、border-colorなどの値を含むかは検討中です。

ID Selectors

"idSelectors": true

IDセレクタを含むセレクタの数です。

Universal Selectors

"universalSelectors": true

ユニバーサルセレクタを含むセレクタの数です。

Unqualified Attribute Selectors

"unqualifiedAttributeSelectors": true

不適切な属性セレクタの数です。

.selected [type=text] { color: red; }

上記はこれに該当しますが、下記は該当しません。なぜならセレクタは右から左へと解析されるので、上記のセレクタの場合すべての要素をチェックするからです。

.selected [type=text] a { color: red; }

• Disallow unqualified attribute selectors · stubbornella/csslint Wiki

Javascript Specific Selectors

"javascriptSpecificSelectors": /[#\.]js\-/g

js-*のようなJavaScript専用のセレクタを含む数です。DOMをJavaScriptから操作する場合、id属性やclass属性をフックとして利用します。これらの属性値にはjs-*のような接頭辞をつけて、JavaScript専用のものとし、これらのセレクタにはスタイルを付与しないほうが、独立性を保てます。

デフォルトの接頭辞にはjs-*を指定していますが、任意の正規表現オブジェクトを渡すことで変更可能です。

参考：

• About HTML semantics and front-end architecture | en.ja Article

Important Keywords

"importantKeywords": true

!importantの宣言数です。

Float Properties

"floatProperties": true

floatプロパティの宣言数です。あれこれfloatしてレイアウトをこねくり回すより、最初からグリッドフレームワークの導入を考えたほうが得策な場合もあります。

• Disallow too many floats · stubbornella/csslint Wiki

Media Queries

"mediaQueries": true

Media Queriesの宣言数です。

Properties Count

"propertiesCount": 10

どのプロパティがどれだけ宣言されているのか、デフォルトではTop10までランキング出力してくれます。大体のCSSの傾向というか、見れて楽しいです。全部見たかったら、{"propertiesCount": 1000}といった風に指定すればよいです。個人的にこれが欲しかったので作ったという背景もあります。

v2.2.1では以上の指標ですが、こういった指標があったら便利だなとか、この指標はこうしたほうがよいなどありましたら、どんどんIssuesをあげてください。よろしくお願いします。

• Issues · t32k/stylestats

CIツールとの統合

stylestats path/to/stylesheet.css -t csv

という風にすればCSV形式で出力できるので、これを使ってJenkins CI上でファイルサイズの変遷など記録したいと思います。

• Plot with Jenkins · t32k/stylestats Wiki

CloudBees社のサービスを使えば、月100分までのビルドが無料でJenkinsをクラウド上で利用できるので、それで試すのもよいかと思います。

Jenkins上で、グラフを作るためにPlot Pluginをインストールします。このプラグインは、Java properties、CSV、XMLにファイルを読み込みんでグラフを生成してくれます。

あとは、NodeJS Pluginなどで、Node.jsとStyleStatsをインストールすれば準備完了です。

ビルドの処理にStyleStatsを実行し、CSVで出力し、ビルド後の処理でそのCSVを読み込んであげれば、完了です。

あとは、GitHubと連携してレポジトリにコミットしたら、ビルドを実行させるなどトリガを設定してもらえればと思います。

File Size:

Style Info:

あとはデータが貯まると、こんなかんじでグラフが生成されます。CSSのリファクタリングは地道な作業ですので、ファイルサイズだけでなく、セレクタ数やルール数など細かい指標の変遷をチェックしていれば、モチベーションも持続できるかと思います。ぜひとも、導入してみてください。

また、ローカルで確認したい場合はGrunt/Gulpプラグインもありますので、そちらを使ってもらえるとよいです。

• tvooo/grunt-stylestats
• 1000ch/gulp-stylestats

今後はtestspecファイルを認識できるようにし、例えばImpotant Keywordsが10個以上だったらテストを失敗させるといったことを、Jenkins・Travis-CIなどでできるようにしたいと思っています。

みなさんもぜひ使ってみてくださいね！

[追記] 2014年4月4日

• Online tool for StyleStats

オンラインでStyleStatsを使えるツールを公開しました。