本記事では、2015/2/21に行われた「Frontrend Conference」のJSトラックセッション「Reactive Programming in JavaScript」から抜粋した内容を紹介します。

「リアクティブプログラミング」（以下、RP）という言葉を、みなさんはご存じでしょうか。RPは、オブジェクト指向プログラミングや関数型プログラミングと同様に、プログラミングパラダイムのひとつです。このRPというパラダイムを、近年のWebフロントエンドの風潮になぞらえて見ていきます。

リアクティブプログラミングという考え方

RPは「イベントや変化する値の関係性」に注目し、これを簡潔に記述することで相互作用を上手に扱おうとするプログラミングパラダイムです。

これはオブジェクト指向プログラミングが「オブジェクトと相互のメッセージング」に注目したり、関数型プログラミングが「関数の作用」に注目したりするように、プログラミングを捉えるときの着眼点、切り口のひとつであるとも言えます。

GUIにとってReactiveは身近な概念

GUIプログラミングにおいて、データ（一般的には、Model）に変化があったときや何らかの非同期処理が終わったときなど、表示（一般的にはView）の更新につながる処理が頻繁に実行されます。

RPでは「イベントや変化する値の関係性 = データフロー」に注目した上で、特に「データフローの宣言によって、片方の変化を他方に自動で伝播させる」ことが重要です。これによって、しばしば複雑になりがちなデータの相互作用を容易に管理できるようにします。

GUIで発生する同期/非同期を問わずに発生する何らかのイベントと、それに伴う画面の更新は「片方の変化を他方に自動で伝播させる」仕組み作りが有効に作用する分野です。

Reactiveなアプローチはフロントエンドでも試みられてきた

Webフロントエンドでは、これまでどのようにReactiveなアプローチが試みられてきたのでしょうか？RPの主題とも言える「データフローの宣言によって、片方の変化を他方に自動で伝播させる」という振る舞いの成り立ちは、作ろうとしているプロダクトの種類や開発言語、使用するライブラリによって異なります。

たとえばMVVM(Model View ViewModel)に代表されるようなデータバインディングの仕組みは、データ（Model）と表示（View）を宣言的に結びつけるReactiveな仕組みと言えます。

今年から特に話題にのぼることが多くなったReactについても、Fluxというアーキテクチャモデルが加わることで、データの変更を表示に伝播させるReactiveなデータフローを実現しようとしています。

Functional Reactive Programming

Functional Reactive Programming（以下FRP）とは、RPのモデルに関数型プログラミング（Functional Programming）の要素を加えたものです。

本セッションではデータバインディングや Fluxに続く（正確にはそれらよりもずっと前からあるものなのですが…）Reactiveなアプローチとして、FRPにという考え方に基づいた Reactive Extensionsと呼ばれるライブラリを紹介していきます。

Reactive Extensions と非同期データストリーム

FRPを基にしたReactive Extensions というライブラリでは、すべての値を「時間軸に沿って値が流れるリスト = 非同期データストリーム」というモデルに落とし込みます。これだけだと、少し分かりづらい概念かもしれません。

参考: Functional Reactive Programming with RxJS

少々強引ですが、今風に喩えて言えば、イベントが起こる度に何度も値を流してくるPromiseと捉えることもできます。それをリストとして捉えることで、mapやfilterといった高階関数を活かした、関数型のイディオムを適用できるようになります。

非同期データストリームのモデルが優れているところは、Promiseのような非同期であっても、散発的に発生する click のような非同期イベント、通常の値であっても、すべて同じモデルに落とし込んでRPを実践できるように抽象化されているところです。

RxJS を利用してみる

ここでは Reactive Extensions の JavaScript実装であるRxJSを取り上げて、一つの例を紹介します。次に示すリンクは、+（プラス）または-（マイナス）をクリックすると、中央の数字が更新されるサンプルです。この中にRxJSで使われる基本的なメソッドが詰まっています。

• RxJSのSample(CodePen)

上記サンプルのJavaScript部分を抜粋してコメントをつけると次のようになります。サンプルの動作自体は簡単なので、らくに読めると思います。中でもストリームやオブザーバを宣言している部分と、それらをどのようにつなぎ合わせているかに注目するとよいでしょう。

document.addEventListener('DOMContentLoaded', function() {

  // 要素のセットアップ
  var plusEl    = document.getElementById('plus');
  var minusEl   = document.getElementById('minus');
  var counterEl = document.getElementById('counter');
  
  // <span id="plus">+</span> を click すると 1 が流れるストリーム
  var plus    = Rx.Observable.fromEvent(plusEl, 'click').map(1);
  // <span id="minus">-</span> を click すると -1 が流れるストリーム
  var minus   = Rx.Observable.fromEvent(minusEl, 'click').map(-1);

  // plusとminusをひとつにマージする
  var both = plus.merge(minus);

  // scanは第一引数に初期値、第二引数にアキュムレータを受け取る
  // curtValueは現在値を示し、bothから1/-1が流れてくるたびに加算する
  var curtValue = both.scan(0, function(acc, v) {
    return acc + v;
  });

  // 流れてきた値を処理するオブザーバを定義する
  var setHtml = Rx.Observer.create(function(v) {
    counterEl.innerHTML = v;
  });

  // curtValue (現在値) に更新があると、オブザーバが動作する
  var subscription = curtValue.subscribe(setHtml);
});

非同期データストリームにほとんどについて、Rx.Observableのインターフェースに集約されており、全て取り上げると莫大な数（150超）のメソッドが実装されています。（APIドキュメント）

いきなり全てのメソッドを把握しようとすると、あまりにも大変ですが、まずは今回のサンプルで登場したような限られたメソッドを把握するだけでも、簡単な動きを作ることはできるでしょう。

• Rx.Observable.fromEvent(element, eventType)
• Rx.Observable#merge(otherObservable)
• Rx.Observable#scan(seedValue, accumlator)
• Rx.Observable#subscribe(observer)

本編セッションでは、より多くのサンプルを紹介しているので動画やスライド資料も参考にしてみてください。

RxJS に影響を受けたその他のライブラリ

Webフロントエンドで利用できるFRPライブラリは、RxJSだけではありません。Reactive Extensions、あるいは RxJSそのものに影響を受けて作られたライブラリが他にあります。

Bacon.jsはRx.Observable相当の概念を、EventStreamというProperty に整理しています。これはReactive ExtensionのObservableにおけるHot/Coldという、やや複雑な概念をシンプルに整理し直したものです。

Kefir.js はBacon.jsと同じ概念を踏襲しつつ、コード実装を最適化して、より優れたパフォーマンスを得ることを目的としたライブラリです。

Reactive Programmingを学ぶ意義

FRPの考え方を忠実に再現しようとすること自体は、現在のフロントエンドにおけるJavaScriptの設計パターンと必ずしもマッチするものではないかもしれません。

しかし、オブジェクト指向言語に関数型のエッセンスが徐々に取り入れられているのと同じように、RPも少量のエッセンスを取り入れることには十分な価値があることでしょう。

本記事では限られた範囲での紹介でしたが、セッションの動画も公開されていますので、もっと知りたい方はそちらもご覧いただけると幸いです。2015年に入ってからReactive ExtensionsまたはRxJS関係の情報も増えてきていますので、今後より一層注目されるようになるかもしれません。

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第4回目、最終回です。

背景画像でリストのビュレットを配置した場合の問題

今回は、前回までの内容を踏まえ、主にインラインブロックについて見ていきます。まずは、以下のようなリストを「HTMLとCSSで作りたい」と思います。この時、リストのビュレットはオリジナルの画像にしたいです。

こんな時、背景画像を利用し、以下のような方法でこの見栄えを再現するという方は多いでしょう。筆者も昔からずっと、この方法で実装してきました。

<ul>
  <li>彼は背後にひそかな...</li>
  <li>それはあまり良い意味を...</li>
  ...
</ul>

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 16px;
  background: url(bullet.png) no-repeat 0 .45em;
}

liの左上を起点に、左から0px、上から0.45emの位置に背景画像としてビュレットを配置するという方法です。

何ら問題のなさそうなこの方法ですが、行の高さや、liの上paddingが変わってしまうと、ビュレットの位置がずれてしまいます。左上を起点に画像を配置しているため、本連載で解説した、アイコン画像をvertical-align:topで配置した場合と似た形になります。例えば、極端にline-heightを高くすれば、以下のようになります。理解しやすさのため、liの上端に赤い線を引いてみました。

こんなに大きくline-heightが変わってしまうことは稀でしょうが、あとからサイト全体のベースとなるfont-size、line-heightを調節したりした場合、この実装を行った箇所のビュレットは、ほんのわずか上下にずれてしまうかもしれません。そのたびに微調節するのはかなり手間です。

IE6、7でも問題なく利用できるというのは。この実装方法の大きなメリットです。それゆえ、昔から多く使われてきました。

インラインブロックを利用してアイコンを表現する

インラインブロックを利用して、この問題を解決した実装例を紹介しましょう。

前回紹介した実装例では、imgをvertical-alignでmiddleに配置し、上下にネガティブマージンを指定することで、ビュレットとして利用していました。以下のサンプルでは、それと同じことをbefore擬似要素で実現しています。

<ul>
  <li>彼は背後にひそかな...</li>
  <li>それはあまり良い意味を...</li>
  ...
</ul>

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 16px;
  text-indent: -16px;
}
li:before {
  content: '';
  display: inline-block;
  background: url(bullet.png) no-repeat 0 0;
  width: 8px;
  height: 8px;
  vertical-align: middle;
  margin: -5px 8px -3px 0;
}

:beforeを利用し、liのはじめにdisplayがinline-blockである擬似要素を配置します。

displayにinline-blockが指定された要素（これを以降インラインブロックと呼ぶことにします）は、中にブロックレベルの要素を入れることができるコンテナとなります。この場合は中に何も入れないため、それについては特に気にする必要がありません。

このインラインブロック、display:inlineが指定されたインライン要素とは異なり、幅と高さを持ち、行をまたがないという特徴を持ちます。その名の通り、文中に入るブロック要素のような存在です。この場合のレイアウト方法は、文中にimg要素を入れた場合……つまり、インラインの置換要素とほぼ同じです。

この例は、img要素としてビュレットを入れたいが、HTMLをシンプルにしたいゆえ、それを擬似要素で代替しているという具合に考えると分かりやすいかもしれません。ここでポイントとなるのは、この擬似要素がvertical-align:middleで配置されているということです。この状態でline-heightの値を上げ、行間を広げると以下のようになります。わかりやすさのため、middleのラインに赤い線を引いています。

middleのラインにimg要素が揃えられるため、行の高さに影響されず、ほぼ中央配置が維持されます。

このように、img要素の代わりとしてインラインブロックを利用すれば、HTMLをシンプルに保ったまま、vertical-alignの柔軟さを利用することができます。

チェックボックスやラジオボタンの配置

本連載の初めに挙げた疑問として、チェックボックスやラジオボタンをうまく配置するにはどうすればよいのか？という点がありました。

そもそも、チェックボックスやラジオボタンを置いた場合、ブラウザはそれらをどのように描画するのでしょうか。HTMLやCSSの仕様書の中から、そのことについて書かれている箇所を探していたのですが、どうもそれらの実装について明確な取り決めはまだあるわけではなく、ブラウザに内容をよしなに描画するよう任せられているというのが現状のようです。現状の実装においては、たいていOSが持っているコンポーネントがそこに配置されるようになっています。

つまるところ、これらは内容の不明確な置換要素であり、その高さや幅はブラウザによって異なると、とらえるしかなさそうです。そうなると、幅がわからないわけですから、今までtext-indentとmarginを利用したビュレットやアイコンの配置方法をそのまま使うだけでは、うまくいきません。

そこで、インラインブロックにしたspan要素でラジオボタンやチェックボックスを囲み、その幅を固定するというアプローチをとったのが、以下の例です。

<ul>
  <li><label><span></span>彼は...</label></li>
  <li><label><span></span>それは...</label></li>
</ul>

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 25px;
  text-indent: -25px;
}
span {
  display: inline-block;
  width: 20px;
  margin: -17px 5px -13px 0;
  vertical-align: middle;
}
input {
  display: block;
  margin: 0 auto;
}

ここでは先ほどスルーした、インラインブロックの「中にブロックレベルの要素を入れることができる」という特徴を利用しています。あとはこれまでの実装と同様、text-indentで左に飛び出させ、その部分に頭に置きたい要素を置くという方法を利用しています。チェックボックスやラジオボタン（以降、input要素）の幅は不定ですが、それを囲むspan要素の幅が20pxで固定されているため、input要素の幅を気にしなくても良いようになっています。

また、高さについてですが、インラインブロックの高さが特別指定されていない場合、内容により自動的に高さが決定されます。この場合は、input要素の高さがそのまま、span要素の高さとなります。そして、このspan要素は、vertical-align:middleで行中に配置されます。この場合、span要素の中央のラインが行のmiddleラインと揃えられるため、input要素の高さを気にすること無く、行のほぼ中央に揃えられます。

なかなかややこしいですが、インラインブロックの特徴を利用すれば、このように細かなレイアウトも柔軟に表現することができます。

インラインブロックを利用したカラムレイアウト

このように便利なインラインブロックですが、普段floatなりで実現されるようなカラムレイアウトにも利用することができます。まず、この単純な例を見て下さい。

<div>Hello! Hello! Hello!</div>

ただ1行のテキストがあるだけです。
ここに、インラインブロックを一つ突っ込んでみます。

<div>
  Hello! 
  <div class="box">...</div>
  Hello!
</div>

.box {
  display: inline-block;
  vertical-align: middle;
}

インラインブロックは外からはimg要素のようにレイアウトされ、その中にはブロックレベルの要素を入れられるのでした。なので、上記のようにレイアウトされます。

ではここで、テキストを全て取り払ってしまい、インラインブロックだけにしてしまったら……以下のようになります。

<div>
  <div class="box">...</div>
  <div class="box">...</div>
  <div class="box">...</div>
</div>

これで、インラインブロックを利用したカラムレイアウトの出来上がりです。上図で緑で塗りつぶしている部分は、行を表しています。インラインブロックの中にはブロックレベルの要素を入れることができるため、これが行なのかと言われるとなんとも不思議な感じです。普段は行の中にはテキストが入っていますが、その代わりにインラインブロックだけを詰めてしまえば、それでカラムレイアウトが実現できるというぐらいです。内容が増えれば行が増え、複数段の段組が実現されます。

このように、インラインブロックを利用して、カラムレイアウトを行うこともできます。

floatを利用したカラムレイアウトの問題点

このインラインブロックで行われるようなレイアウトは、旧ブラウザまで対応するとなると、floatを利用して実現することが多いはずです。例えば以下の様な「レイアウトを実現したい」とします。

こんな時、例えば以下の様なコードになりそうです。

<div class="items">
  <div class="item">...</div>
  <div class="item">...</div>
  <div class="item">...</div>
  <div class="item">...</div>
  ...
</div>

.item {
  float: left;
  width: 25%;
}

一見問題なさそうですが、悲しいことに、この描画結果は以下のようになってしまいます。

細かい話は割愛しますが、このようにfloat:leftされた要素が連続すると、左上から詰めて配置されるようなレイアウトが行われるため、上記のような描画結果になってしまいます。

これは望んだ結果とは異なります。これを解決するには、この場合、例えば4つごとにcler:leftを指定したり、4つごとを別のdiv要素で囲み、clearfix的な指定を行うなどという方法が必要とされます。

インラインブロックを利用した解決方法

こんなとき、インラインブロックを利用すると、シンプルなHTMLで同様のことを実現できます。以下がその例です。

<div class="items"><!--
  --><div class="item">...</div><!--
  --><div class="item">...</div><!--
  --><div class="item">...</div><!--
  --><div class="item">...</div><!--
  ...
--></div>

.item {
  display: inline-block;
  vertical-align: top;
  width: 25%;
}

これで、望んでいたレイアウトは実現されます。4つごとに何かする必要もありません。先ほどのインラインブロックを利用したカラムレイアウトの例に習えば、ここでは、以下のように、3つの行ボックスがあり、その中にインラインブロックが積まれていると考えられます。

そして、これらインラインブロックは、vertical-align:topで配置されているため、上端で揃えられています。

見た目上はこれが行などとは全く思えませんが、このように行のレイアウトを利用すると、柔軟なカラムレイアウトも実現することができます。現状、これと同じようなことをしたかったら、Flexboxを利用する必要があるように思います。

ちなみに、この例でdiv要素間に入れている変なコメントは、改行やタブを殺すためのものです。改行やタブが存在しているとホワイトスペースがそこにあることになり、そのぶん、領域が確保されてしまいます。このカラムレイアウトの方法自体は、本来行の中で行われる細かな部分のレイアウトを行うための仕組みを利用したものであり、仕様的には正しいものの、トリッキーな応用であるという点を忘れてはいけないでしょう。

まとめ

以上、全4回に渡り、行の中で行われる種々のレイアウト方法について解説してきました。筆者自身、普段何気なく使っていたプロパティでしたが、改めて突っ込んで調べてみたところ、以前よりも意図通りに正確にレイアウトが行えるようになったように感じています。ミクロなレイアウト制御からマクロなレイアウト制御まで、色々と応用の効く知識であると思いますので、CSSの書き方に悩んだらこの連載で取り上げた内容を思い出してみると、応用できる場合もあるかもしれません。

CodeGridについて

この連載の内容は、弊社、株式会社PixelGridが運営するフロントエンドの技術情報を配信するサービス、CodeGridにて連載された内容を元にしています。ご興味があれば、こちらもチェックしていただけると幸いです。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第3回目です。

vertical-alignごとのアイコンの揃え位置

前回に引き続き、vertical-alignの利用方法について解説していきます。今回はまず、文頭に置いたアイコン画像を、vertical-alignを用いて位置調節する方法から見ていきます。

以下の様なHTMLがあったとします。

<ul>
  <li><img> xAhy 鈴</li>
  <li><img> xAhy 鈴</li>
  <li><img> xAhy 鈴</li>
  ...
</ul>

ここで配置されているimg要素は、文頭にあるアイコンのようなものを想定して下さい。このようにアイコンを配置する時、そのままだとなんだかアイコンの位置がイマイチうまい位置に配置されないことがあります。そんな時にどうすればよいか。それはこのimg要素のvertical-alignを調節すればいいのですが、これをどう調節すればよいかは悩みどころですね。

先に答えを言ってしまうと、筆者的にはvertical-align: middleを指定するのが一番無難であるように思いました。前回までの内容を踏まえ、このアイコン画像のvertical-align値を変えてみるとどうなるのか、見てみます。

vertical-align: top

まずはtopです。文頭に置いたアイコンのサイズをいろいろと変えてみました。このとき、imgにvertical-align: topを指定すると、以下の様な表示になります。（わかりやすさのためにliには背景色をつけてあります）

img {
  vertical-align: top;
}

topが指定された場合、行の上端に画像の上端が合わせられます。

この場合ですと、画像の高さが行の高さと同じぐらいでないと、ちょうどよい位置に配置するのは難しそうです。アイコンのデザイン基準位置が上端であったならばアリかもしれませんが、そういったことは稀でしょう。今回のような用途でtopを指定することは、ほとんどなさそうです。

vertical-align: bottom

次はbottomの場合です。

img {
  vertical-align: bottom;
}

bottomが指定された場合、行の下端に画像の下端が合わせられます。

この場合もtopと同様に、画像の高さが行の高さと同じぐらいでないと、利用価値はなさそうです。ただ、アイコン画像が、文字の高さよりも少し大きいぐらいでばらつきがあり、なおかつ画像の下端を基準としたようなアイコンであれば、bottomを指定するのはアリかもしれません。

vertical-align: text-top

次はtext-topの場合です。

img {
  vertical-align: text-top;
}

text-topが指定された場合、inline boxの上端に画像の上端が合わせられます。

この場合は、アイコンの高さが文字の高さぐらいであれば、ちょうど真ん中に揃えられそうです。しかし、アイコンが大きい場合は、アイコンが下に飛び出るように配置されるため、おかしな配置となってしまいそうです。アイコンを配置する用途として利用する機会は少なそうに思います。

vertical-align: text-bottom

次はtext-bottomの場合です。

img {
  vertical-align: text-bottom;
}

text-bottomが指定された場合、inline boxの下端に画像の下端が合わせられます。

text-topと同様、アイコンの高さが文字の高さぐらいの場合にはちょうどよいですが、アイコンが大きい場合は、アイコンが上に飛び出ます。アイコンの高さにばらつきがあり、その高さが文字の高さを超えないぐらいなのであれば、ちょうどよい位置に配置することができそうです。

vertical-align: baseline

img {
  vertical-align: baseline;
}

次はbaselineの場合です。vertical-alignの初期値はbaselineですので、特に何も指定しなければこの方法でレイアウトされます。

baselineが指定された場合、baselineに画像の下端が合わせられます。

この指定が有効なのは、画像の高さが、x-heightの高さ〜文字の高さの範囲である場合でしょう。それよりも大きな画像の場合は、アイコンが上側に飛び出ているように見えてしまいます。このため、特に何もCSSで調節しないままアイコンを置いたら、どうも上めに配置されてしまうな〜と感じる方は多いのではないでしょうか。

vertical-align: <length>

次はlengthの場合です。3pxとか0.3em等が指定された場合です。ここでは、4pxを指定しました。

img {
  vertical-align: 4px;
}

lengthが指定された場合、baselineから、length分、上方向にずれた位置に画像の下端が揃えられます。

上記レンダリング結果を見てわかる通り、baselineよりも上にずれてしまっては、かなり小さいアイコンを使う場合にしか、利用価値はなさそうに思えます。ただ、例えば-3pxや-0.2emのように、マイナスの値を指定した場合、baselineよりもその分だけ下にずれた位置に画像の下端が揃えられます。

これを利用すれば、アイコンの下端位置を微調節できるため、アイコンの高さにある程度のバリエーションがあっても、うまく位置調節に利用できそうです。筆者はこの方法でこういったアイコン画像をよく調節していました。恥ずかしながら、なんとなく指定したぶんズレるぐらいにしか理解していませんでしたが……。

vertical-align: middle

次はmiddleの場合です。

img {
  vertical-align: middle;
}

middleが指定された場合、baselineよりもx-heightの高さの半分だけ上の位置に、画像の中央位置が揃えられます。

ここまでで紹介してきたほかプロパティと異なり、画像の「中央」の位置が揃えられるというのが、middleの便利なポイントかと思います。ここまでで紹介してきた他の値では、画像の上端か下端がいずこかに揃えられます。中央で揃えてくれるのはmiddleだけです。ちなみに、centralという、行の中央に画像の中央が揃えられる指定もありますが、ブラウザのサポートはまだまだのようです。

微調整を加えた例

ほとんどの場合、middle指定すれば、だいたいよい感じに中央に揃ってくれるのではないでしょうか。ただし、アイコンの高さによっては、やや下寄りにアイコンが寄っているように見えてしまうかもしれません。

例えば、アイコンの高さがちょうど文字の大きさぐらいで、アイコンに続くテキストが日本語である場合、そのように見えてしまう可能性が高いと私は感じます。これは、日本語の文字というものは、アルファベットと比較した場合、文字の上方まで密度が高く作られていることが多いためです。第1回で軽く触れましたが、日本語の文字のbaselineは、アルファベットのbaselineよりも少し下にあります。

そして、ほとんどの文字は、このbaselineよりも下方のスペースを利用しません。平仮名や漢字の書体を思い浮かべてみてください。gとかjとかいったように、下に伸びる文字は、日本語の中にはあまりなさそうです。それゆえ、日本語の文字というのは、アルファベットの文字と比較すると、行のやや上寄りに寄っているように見えるのではないでしょうか。

これを微調節すれば丁度真ん中ぐらいに見えるのでは？というのが、以下の様な微調整のアプローチです。

img {
  vertical-align: middle;
  position: relative;
  top: -0.1em;
}

このようにすると、以下のように、middleで揃えた位置から若干上寄りにアイコンが配置されます。（左がmiddle、右が微調整したもの）

レンダリング結果は、以下の様な形になります。

本当にちょっとだけ上に寄っているだけですけれども……。img要素の上下のmarginを微調節したり、このように相対配置をし、上めにずらすと、日本語と並べた時に自然になるように筆者は思います。

アイコンをリストのビュレットとして使う

ここまででアイコンの位置を調節するため、img要素のvertical-alignをいろいろといじってみてきました。ですが、このままではリストのビュレットのようには利用できません。以下のように、2行以上になれば、2行目以降は当然アイコンの左端からテキストが始まってしまいますし、アイコンのサイズが大きくなれば、その行の高さはそれに合わせ、大きくなってしまいます。

これを解決する実装例を一つ紹介します。以下です。

<ul>
  <li><img>彼は背後に...</li>
  <li><img>それはあまり...</li>
  <li><img>彼は背後に...</li>
</ul>

ul {
  list-style-type: none;
}
li {
  padding: 0 0 10px 32px;
  text-indent: -32px;
}
img {
  width: 24px;
  height: 24px;
  margin: -14px 8px -10px 0;
  vertical-align: middle;
}

リストマーカーだけを左に飛び出させているのがliに指定した左paddingと、text-indentです。ここではliの左側に32pxのpaddingが指定されています。これでは左に余白ができてしまうだけですが、ここでtext-indent: -32pxを指定します。すると何が起こるかというと、liの1行目だけ、文字が本来の開始位置よりも32px左にずれた箇所から開始されます。つまるところ、1行目だけは、左にpaddingが指定されていないかのように配置され、2行目以降では、左に32pxのpaddingが指定された状態になります。

このように1行目だけ左にめり込んでいるような状態で、liの始めにimg要素を置きます。このimg要素の幅は24pxで、右に8pxのmarginが取られています。つまり、これらを合計した32pxのスペースは、画像とその右マージンが占めることになります。これに続けてテキストが配置されるため、結果として、アイコン画像が左に飛び出しているような結果を得ることができます。

もう一つの問題、「img要素の高さが大きい場合に行の高さが広くなってしまう」については、img要素の上下のネガティブマージン（上-14px、下-10px）で解決しています。このようにマージンを指定すると、画像の上端が上に14px、下端が下に10pxずれる形となり、画像の高さが24pxなので、結果として高さが0の要素を配置しているかのように扱われます。また、middleの位置からすると、上に2pxずれた位置に配置されます。

こういった実装は、本来であればlist-style-imageで行いたいところですが、いろいろと融通が効かないため、筆者はこのような方法を採用しています。

ほか、テンプレート設計のテクニックとしては、アイコンの幅高さを揃えてしまうという点も、一つ重要なように思われます。余白をギリギリまで削れば画像サイズを最小にできるでしょうが、そこまではせず、ある程度の余白をもたせ、高さ24px、幅24pxで作るよう統一したりなどします。そうすれば、一つ一つのアイコンのサイズを考慮し、細かく微調節せずに済むでしょう。そのサイズのアイコンがうまい位置に配置されるよう、今回解説してきたような調整を行えば、大体において、うまい具合にアイコンを配置することができるのではないでしょうか。

次回はdisplay: inline-blockの利用について解説します。

CodeGridについて

この連載の内容は、弊社、株式会社PixelGridが運営するフロントエンドの技術情報を配信するサービス、CodeGridにて連載された内容を元にしています。ご興味があれば、こちらもチェックしていただけると幸いです。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第2回目です。

なぜ画像の下部にスペースができてしまうのか？

今回の記事では、vertical-alignについて解説していきます。前回は、行のレイアウトが、font-sizeとline-heightによりどう変わるのかを見てきました。この行の中で、要素を縦位置のどこに配置するかを決定するのがvertical-alignです。これを理解すると、前回の疑問、「なぜ画像の下部にスペースができてしまうのか」が分かります。

行の中にdisplayがinlineであるimg要素が登場したときのことを考えていきましょう。このときのimg要素は、そのvertical-alignの値により、配置される場所が異なります。順に見ていきます。

top, bottom

まずはtop、bottomの場合です。

topの場合は、行の上端であるbefore-edgeに画像の上端が合わせられるように配置されます（A）。bottomの場合は逆で、行の下端であるafter-edgeに画像の下端が合わせられるように配置されます（B）。つまり、topであれば上端にくっつくよう、bottomであれば下端にくっつくように配置されるのです。そして、行の高さはその内容にあわせて高くなります。

以下がtopの場合です。

行の上端に画像の上端が合わせられ、下部に行が拡張されます。

以下がbottomの場合です。

topの時とは逆で、行の下端に画像の下端が合わせられ、上部に行が拡張されます。

では、前回はじめに上げた例、<div><img></div>のimg要素のvertical-alignを変更してみます。ここでは、わかりやすさのために、<div><img> xAhy 鈴</div>と、テキストを後ろに足しています。まずはtopの場合です。

行の上端に画像の上端が揃えられ、下部に行が拡張されています。

次はbottomの場合です。

今度は逆で、行の下端に画像の下端が揃えられ、上部に行が拡張されています。

text-top, text-bottom

次はtext-top、text-bottomの場合です。

text-topの場合は、text-before-edgeに画像の上端が合わせられるように配置されます（C）。text-bottomの場合は逆で、text-after-edgeに画像の下端が合わせられるように配置されます（D）。font-sizeにより確保される領域の上端がtext-before-edge、下端がtext-after-edgeでした。この位置というのは、line-heightがいくら高くても関係ありません。簡単にいえば、文字のちょっと上にくっつくのがtext-top、文字のちょっと下にくっつくのがtext-bottomです。

そして、先程と同様、行の高さはその内容により高くなります。

以下がtext-topの場合です。

font-sizeにより確保される領域の上端、text-before-edgeに画像の上端が合わせられ、下部に行が拡張されます。

以下がtext-bottomの場合です。

text-topの時とは逆で、text-before-edgeに画像の下端が合わせられ、上部に行が拡張されます。

この2つのパターンの時、図の青矢印で示した部分、つまり、before-edgeとtext-before-edgeの間、text-after-edgeとafter-edgeの間には、画像が侵入しないことに注目してください。この部分はどのようになっているか、先の例と同様、色を付けたサンプルで見てみましょう。まずはtext-topの場合です。

そして次は、text-bottomの場合です。

先の図で、青矢印で示した箇所がスペースとして確保されているのが分かります。

baseline, middle

次はbaseline、middleの場合です。

baselineの場合は、baseline（alphabetical baseline）に画像の下端が合わせられるように配置されます（E）。middleの場合は、img要素の高さの中央が、baselineからx-heightの高さの半分上の位置に揃うように配置されます（F）。

これまでと同様、行の高さはその内容により高くなりますので、その様子を見てみます。

以下がbaselineの場合です。

baselineに画像の下端が揃えられるため、行は上に拡張されます。ということは、baselineよりも下に画像が侵入することはありません。

以下がmiddleの場合です。

middleの場合は、画像の中央のラインで揃えられるため、画像の高さが高くなった場合、上下に行が拡張されます。

では、先程と同様、色を付けたサンプルで見てみましょう。

以下がbaselineの場合です。

ベースラインよりも下に画像が侵入することはありませんが、ベースラインより下も行の一部です。よって、このように画像下部にスペースが確保された状態になります。先の図で青矢印で示した箇所です。

そして次はmiddleの場合です。

画像の高さが高くなれば、行は上下にどんどん広がります。この時に余計なスペースは発生していません。

<length>

最後はlengthの場合です。3pxとか0.3em等が指定された場合です。

lengthが指定された場合は、baselineよりその長さ分だけ上のラインに画像の下端が揃えられるわけですから、それよりも下側の部分が余白となります。

色を付けたサンプルで見てみましょう。

baselineを指定したときよりも、広いスペースが下に確保されているのが分かります。

画像下部のスペースの謎

今回は、img要素のvertical-alignに様々な値を指定してみた場合を詳しく見てきました。もう既にお気づきかと思いますが、画像下部のスペースというのは、行として確保される領域の一部です。img要素の初期vertical-align値はbaselineです。よって、その場合に発生する画像下部のスペースというのは、baselineからafter-edgeまでの領域のこととなります。

これが、画像下部に発生する余分なスペースの謎でした。ただimg要素を置いただけだと、インライン要素が配置されただけなので、それは、行ボックスの中に配置されることになります。そうなると、行各部の領域が確保されてしまうこととなりますので、意図しない余白に悩まされてしまうかもしれません。

こんな時はどうすればいいかといいますと、行ボックスを作らなければよいのです。早い話、img要素にdisplay: blockを指定してやるのが一番でしょう。ブロックとして表示させたい要素にはちゃんとdisplay: blockを指定する……と、考えて見れば当たり前の話ではありますが。

次回は、今回までの連載内容を活かし、リストのビュレットをうまく配置する方法を解説します。

CodeGridについて

この連載の内容は、弊社、株式会社PixelGridが運営するフロントエンドの技術情報を配信するサービス、CodeGridにて連載された内容を元にしています。フロントエンド関する様々な情報を毎週配信しています。ご興味があれば、こちらもチェックしていただけると幸いです。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

本記事は、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を扱う私たちの価値も上がっていくのではないでしょうか。

この記事は、Frontrend Conferenceのセッション「Inline layout」でお話させていただいた内容を基に、連載記事（全4回）として書き起こしたものです。今回は第１回目です。

はじめに

Frontrend Conferenceでは、皆さんが新しい技術について話していた中、私からはCSS2.1のお話をさせていただきました。私が解説したのは、CSSを書く上で欠かせない、以下の4つについてです。

• font-size
• line-height
• vertical-align
• inline-block

トレンドとはほど遠い内容ではありますが、多くの人にとって、なんとなく感覚的に書いてしまっている部分だったという感想をいただきました。本記事の内容を理解すれば、日頃のコーディングの悩みがすっきりするかもしれません。

なお、この連載の内容は、弊社、株式会社PixelGridが運営するフロントエンドの技術情報を配信するサービス、CodeGridにて連載された内容を元にしています。フロントエンド関する様々な情報を毎週配信しています。ご興味があれば、こちらもチェックしていただけると幸いです。

レイアウトの仕組み、正しく理解できていますか？

こんなHTMLがあったとします。

<div><img></div>
<div><img></div>

この時、以下のように画像が並べられますが、画像の下部には、何かわずかなスペースが発生してしまいます。

このスペースは、以下の様なCSSを書くと、消すことができます。

img { vertical-align: top; }

このスペースは一体何か。なぜvertical-alignを書くと消えたのか。私はなぜこのようなことになるのか、よく分かっていませんでした。

また、以下のようにアイコン画像やラジオボタン、チェックボックスをリストの頭に配置するのは、よくあることです。

しかし、このアイコン画像ら、なかなかうまい位置にレイアウトされないことがあります。上記画像のように、少し下や上にずれてしまったり。ここでvertical-alignをいじったり、position: relativeにしてわずかに上や下にずらしたりなどして調節したりする人は多いでしょう。ですが、そもそも、なぜこのようにうまくレイアウトされないのか。どうすればうまく調節できるのか。それを調べていったところ、結果として、インラインのレイアウトについて詳しく理解するに至りました。

普段何気なく使っているけれど、実は詳しくは知らない（かもしれない）、インラインのレイアウトについて解説していきます。

font-sizeとline-height

まずははじめに疑問として挙げた、画像下部に発生するスペースについて考えていきましょう。……と言いたいところですが、その前に、これを理解するにはまずfont-sizeとline-heightの理解が必須です。今回はこれを解説していきましょう。

次のようなHTMLとCSSがあるとします。

<p><span>The quick brown fox jumps over the lazy dog. ...</span></p>

p {
  font-size: 16px;
  line-height: 16px;
  background: #a6dbbe; /* green */
}
span {
  background: #f197f1; /* purple */
}

これは、以下のように描画されます。

このとき、文字の大きさは16pxで、行の高さも16pxです。それぞれの行を枠で囲んでみると、以下のようになるでしょう。

ここで、line-heightを広げてみます。

p {
  font-size: 16px;
  line-height: 24px;
}

すると、以下のように行の間にスペースが発生します。

この時の文字の大きさと行の高さについて、詳しく見ていきましょう。

ピンクの間に見える背景のグリーンの部分が、line-heightを指定することで広げられた「行間」となりますが、この部分のことをleadingといいます。

このleading、次のように、真ん中で半分に分割されます。このように半分に分割されたleadingをhalf-leadingと呼びます。

1行というのはfont-size分の高さを持った基本領域（inline box）の上下にhalf-leading分のスペースが加わり、成り立っています。このとき、1行の高さはline-heightが示す値、この場合でいうと24pxです。この値から基本領域の高さ16pxを引いた8pxがleadingの高さとなり、half-leadingの高さは4pxとなります。図にすると以下のような形です。

line-heightを変えると、この緑で示したleading部分の高さが変化することとなります。

行内の各部名称

行の中では、このように文字上下のスペースが確保されるようになっています。各部には、以下のように名前がつけられています。

テキストが配置される場合、まず始めに、それを配置するための箱が用意されると考えます。この箱のことをinline boxと呼びます。上図にて、紫で色を付けた領域です。テキストが配置される場合、このinline boxの高さが、1em分の高さです。

例えばfont-size: 16pxと指定したら、このinline boxの高さが16pxとなり、16pxが1emとして扱われるようになるという具合です。

そして、その上下にhalf-leading分の余白が加わり、1行の高さとなります。この高さがline-heightが示す高さとなります。こうして拡張されたinline boxのことを、extended inline boxと呼びます。line-heightが24pxなら、extended inline boxの高さが24pxとなります。

このinline boxの上端をtext-before-edge、下端をtext-after-edge。extended inline boxの上端をbefore-edge、下端をafter-edgeと呼びます。

インラインのレイアウトを考える上で重要なのが、baselineです。

baselineとは、その名が示す通り、文字の土台となるラインです。アルファベットの文字は通常、このbaselineを基準としてデザインされます。そして、ここから一定の距離のラインで、小文字の高さを揃えます。この高さがx-heightです（この高さは、CSS内で1exとして利用できます）。

ちなみに、このbaselineはアルファベットを基準に考えた場合で、日本語などのbaselineは、これよりもちょっと下がbaseline（ideographical baseline）となります。

CSS3の仕様を見ると、将来的には、このideographical baselineもvertical-alignなどの基準位置として利用できるようになるようです。

行の高さ

行というのは、テキストを配置するのに必要な分だけ作られます。そして、その高さは、各行それぞれにおいて決定されます。以下のようなHTMLとCSSがあったとします。

<p>The <b>quick</b> <em>brown</em> <i>fox</i> jumps...</p>

そして、各要素に異なるfont-size、line-heightと色を指定します。

p  { font-size: 12px; line-height: 18px; }
b  { font-size: 20px; line-height: 30px; }
em { font-size: 30px; line-height: 40px; }
i  { font-size: 40px; line-height: 50px; }

すると、以下の様な描画結果となり、当たり前のことですが、pの中にたくさんの行が発生していることが分かります。

ここで、1行目を詳しく見てみると、以下の様にレイアウトが行われています。

b、em、iそれぞれの要素は、それぞれに指定されたline-heightの分だけの高さを持つextended inline boxを形成します。その前後のテキストは、pのline-heightが適用されます。こうして、複数のextended inline boxが一つの行の中に存在する場合、その中で最も高さの高いボックスの高さが、行の高さとなります。この場合は、<i>fox</i>が50pxで一番高いので、この高さが行の高さとなっています。これが基本的な行レイアウトの仕組みです。そして、これらのボックスは、ベースラインに沿って揃えられます。この揃え位置をいろいろと変更できるのがvertical-alignです。

今回は、font-sizeとline-heightにより、どのように行がレイアウトされるのかを解説しました。次回はvertical-alignについて解説していきます。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

本記事は、2015/2/21に行われたFrontrend Conferenceの「Introduction To React」の内容を紹介します。

当日の資料は以下にアップされていますので、こちらも参照してください。

Introduction To React // Speaker Deck

React.jsとは何か

React.jsはFacebook製のJavaScriptライブラリです。

http://facebook.github.io/react/

公式サイトに、「A JavaScript library for building user interfaces」とあるように、React.jsはUIを構築するためのライブラリです。フレームワークでなくあくまでUIを構築するだけのライブラリで、MVCでいうところのVのみの機能を提供します。

開発を行っているFacebookやInstagramはもちろん、YahooやAirbnbなど多くの採用事例があり、現在注目を集めているライブラリの一つです。

React.jsの特徴

React.jsの特徴を知るために、まずは他のライブラリやフレームワークの問題点について見ていきましょう。例えばTodo MVCのような、フォームを送信したらリストに項目が追加されるようなUIの実装を考えてみましょう。

jQuery

単純にjQueryだけで実装すると次のようになるでしょう。

// Submitされたら
$('form').on('submit', functino() {
  // 要素作って
  var $li = $('<li>');
  // ...

  // リストに追加
  $('ul').append($li);
});

しかし、これだとデータがDOMにしかないので、何か機能を追加しようとしたときに非常にやりづらいですし、テストも書きにくいコードになります。

Backbone.js

Backbone.jsを使うとこの問題をある程度解決することができます。Backbone.jsはデータは管理するModelと、表示を管理するViewに分け、さらにViewをコンポーネントごとに分けるという設計を提案します。例えば次のようになります。

var FormView = Backbone.View.extend({
  onSubmit: function() {
    // dataを作ってモデルに追加するだけ
    this.collection.add(data)
  }
});

var ListView = Backbone.View.extend({
  initialize: function() {
    // モデルが更新されたらリストを更新
    this.collection.on('add', this.render);
  }
});

FormViewやListViewといった、UIの部品ごとに機能を分けていますが、このようなものをここではコンポーネントと呼ぶことにします。

Backbone.jsでデータやコンポーネントを分けて管理できるようになるとある程度の規模ではうまくいきますが、Viewの更新処理を手動で書かないといけない面倒さがあったり、ModelとView間のイベント管理が煩雑になるなど、規模が大きくなった時にスケールしづらいという問題があります。（Backbone.jsのラッパーライブラリであるMarionetteやChaplinといったものもありますが、本質的な問題は同じです）

Angular.js、Vue.js

Angular.js、Vue.jsなどに代表される、いわゆるMVVM系のライブラリの特徴はデータが変更されたら自動的に表示が変わる、という考え方です。

<form ng-submit="onSubmit()">
  <input type="text" ng-model="text">
</form>

<ul>
  <li ng-repeat="item in list">
    {{item.text}}
  </li>
</ul>

// Controller
$scope.onSubmit = function() {
  // データを更新したら勝手にViewが変わる
  $scope.list.push(newItem);
};

このように、HTMLに描画されるデータを記述し、JavaScript側ではデータを更新するだけで自動的に表示が更新されます。しかし、これらのライブラリも、規模が大きくなってきた時に状態を管理するのが難しくなってきます。

React.js

jQueryやBackbone.js、Angular.jsは規模が大きくなったときに管理するのが難しくなる、と述べましたが、きちんと設計すれば管理しやすいアプリケーションにすることは可能でしょう。しかし、それらは元々そのような目的のためのライブラリではないので、規模が大きくなっても管理可能に設計するというのは簡単なことではありません。

React.jsは、規模が大きくなっても管理できるような仕組みを提供してくれるライブラリです。逆に言えば、小さいアプリケーションを高速に開発するためのライブラリではないので、そういった場合はBackbone.jsやVue.jsを使ったほうがいいケースが多いと思います。

React.jsの特徴として、コンポーネントを極力ステートレスにすることで、コンポーネントを管理しやすくするというものがあります。

var Form = React.createClass({
  onSubmit: function() {
    // 親にデータの更新を通知
  },
  render: function() {
    return <form onSubmit={this.onSubmit}>...</form>;
  }
});

var List = React.createClass({
  render: function() {
    // 親からもらったデータを元に構築するだけ
    return <ul>{this.props.list.map(...)</ul>;
  }
});

各コンポーネントは親からデータをもらい、それを元にViewを構築します。ここで重要なのは、コンポーネント自身は状態を持たないということです。常に外部（多くの場合は親コンポーネント）からの入力によって一意な表示を出力することでテストしやすく、管理可能で再利用性の高いコンポーネントにすることができます。

もちろん、全てのコンポーネントが状態を持たないと単なる静的なHTMLと同じですので、状態を持つコンポーネントも必要になりますが、そのようなコンポーネントを最小限にし、基本的にはステートレスなコンポーネントを作って組み合わせていくのがReact.jsにおけるプログラミングの考え方です。

普通はツリーのルートのコンポーネントだけに状態を持たせ、その状態を子のコンポーネントに伝え、ツリーを構築します。

また、コンポーネントの状態が変更すると自動的にツリーは再構築されるので、表示の更新を手動でやる必要がありません。これはAngular.jsなどのような、データが変わったら自動的に表示が変わるという考え方と同じです。

基本的にはルートのコンポーネント以外は状態を持たないようにするのがよいですが、input要素などはユーザーアクションによって自身のデータを変更する必要があるので状態を持ちます。

Virtual DOM

ルートのコンポーネントだけで状態を持ち、その状態が変更したらツリーを再構築するというのは、非常に設計を単純にしますが、一部分の変更だけで毎回全てのDOMツリーを再構築するのは速度的な面で問題になります。そこでReact.jsはVirtual DOMという仕組みを導入しました。

Virtual DOMはざっくり言うと、JavaScriptのオブジェクトとしてDOMツリーのようなものを持っておき、データに変更があった場合にそのオブジェクトの差分を計算し、実際のDOMへの再レンダリングを最小限にするという仕組みです。

React.jsではReact.createClassでコンポーネントを作成し、renderメソッドの返り値にVirtual DOMの定義を返します。Virtual DOMはReact.createElementによって作成します。

var MyComponent = React.createClass({
  render: function() {
    return React.createElement("div", {className: "foo"}, 
      React.createElement("div", {className: "bar"},
        "Hello ", this.props.name
      )
    );
});

また、JSXという独自シンタックスを使うことで、XMLのようなシンタックスでVirtual DOMを表現することができます。

var MyComponent = React.createClass({
  render: function() {
    return (
      <div className="foo">
        <div className="bar">
          Hello {this.props.name}
        </div>
      </div>
    );
  }
});

これはreact-toolsやbabelのようなツールで実行可能なJavaScriptのコードに変換することができます。

React.jsの速度について

React.jsは速い、と聞いたことがある人もいるかもしれませんが、はたして本当でしょうか。Virtual DOMという仕組みを導入し、ルートのデータを変更してもDOMへの変更が最小限になるので、高速になりますが、それはあくまでも全てのDOMを再構築する場合と比べた場合の話です。ここでは以下の3つのケースについて速度を計測しました。

1. Backbone.jsで変更があった部分だけDOMを再構築
2. Backbone.jsで何か変更があった場合全てのDOMを再構築
3. React.jsで何か変更があった場合Virtual DOMの仕組みを通して差分のみDOMを再構築

結果は次のようになります。

※ TodoMVC Benchmark

このように、React.jsは、Backbone.jsで部分的に再構築するよりは遅いが、全てのDOMを再構築するよりははるかに速いことがわかります。

前述したように、状態をルートのコンポーネントだけに持つというのは非常に設計を単純にできます。そのような設計と速度を両立できるのがReact.jsの一番の特徴といえるでしょう。

Flux

Fluxはアプリケーションの設計手法の一つとしてFacebookが提唱しているものです。よくMVCと比較され、MVCと比べてデータの流れが一方通行であるという特徴があります。

引用元：http://facebook.github.io/flux/docs/overview.html

ここまでで、React.jsの基本的な設計として、状態をルートコンポーネントに持ち、何か変更があったらその状態を変更すると述べてきましたが、どのようにその変更を通知するかについては触れませんでした。

例えば、ツリーの末端のコンポーネントで何かユーザーのアクションを検知し、状態の変更が必要になったとします。このとき、React.jsではこの末端のコンポーネントはステートレスなので、変更を外に通知する必要があります。このとき、変更があった場合のイベントを公開しておき、直接の親のコンポーネントにイベントハンドラを通して通知する方法があります。

var Parent = React.createClass({
  handleChange: function(changedData) {
    // 子で何か変更があった時の処理
  },
  render: function() {
    // 子のコンポーネントのイベントにハンドラを設定
    return <Child onChange={this.handleChange}>a</Child>;
  }
});

var Child = React.createClass({
  handleSubmit: function() {
    // 親から受け取ったイベントハンドラを実行
    this.props.onChange(changedData);
  },
  render: function() {
    // formのDOMイベントにハンドラを設定
    return <form onSubmit={this.handleSubmit}>...</form>;
  }
});

しかし、この方法だと、ネストが深いところのコンポーネントの変更を状態を持っているルートコンポーネントに伝えるのは非常に面倒です。そこで、FluxではViewで起こった変更を一括でActionに通知し、Dispatcherを通じてStoreに変更を通知します。

Storeというのはデータを管理する層で、MVCでいうMにあたる部分です。ViewのルートコンポーネントはこのStoreの変更を購読しており、Storeが変更されると自動的に状態が変更されます。

Flux自体は、設計の考え方なので、色々な実装があります。Fluxの考案元であるFacebookにもfacebook/fluxという実装がありますが、これはDispacherのみを提供するかなりミニマムな実装です。他には、例えば次のようなものがあります。

• spoike/refluxjs
• jmreidy/fluxy
• yoshuawuyts/barracks
• BinaryMuse/fluxxor
• deloreanjs/delorean

まとめ

React.jsやFluxの思想・特徴について説明しました。文中でも述べたように、React.jsが提供するのは規模が大きくなってもスケールできるような仕組みで、小さいアプリケーションを高速に開発するためのライブラリではありません。そのようなアプリケーションはAngular.jsやVue.jsのほうが向いている場合も多いですし、静的なページにちょっとしたUIをつけるだけならjQueryだけで十分なケースもあります。

実際にReact.jsとFluxでアプリケーションを書いてみるとわかりますが、ステートレスなコンポネートを組み合わせていくというのは面倒だと感じることも多いです。しかし、その面倒な制限と引き換えに得られるのが堅牢でメンテナンス可能なアプリケーションです。

もしそのような仕組みがほしいと思っている方がいればReact.jsも採用の候補に考えてみてはいかがでしょうか。

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

本記事は、2015/2/21に行われた「Frontrend Conference」のファイナルセッション「Styling Atom(Editor)」の内容を紹介します。

オーバービュー

スピーカーはスイス生まれで、現在札幌で受託開発を行っている、Simon（ニックネーム：Simurai）さん、逐次通訳をHTML5 Experts.jpのエキスパートである斉藤祐也さんが努めました。

昨今、様々な企業サイトでのCSSの利用方法が公開されるようになってきました。CSS-Tricks（http://css-tricks.com/css/）に代表的なサイトの一覧が紹介されています。このセッションについても、CSS-Tricksに習って、Atom EditorでどのようにCSSが利用されているかを紹介します。

尚、本記事は、セッションの内容をそのままレポートにしているのではなく、Simuraiさんのセッション内容を基に私の方で再構成した、イベントレポートとなっています。

Atom Editorとは

Atom Editorは、GitHubが中心となりオープンソースで開発されているhackable text editorです。

Atom EditorはWindowsやMac上で動作するデスクトップアプリケーションであり、普通にインストールして利用することができます。しかし、内部的には、HTML/CSS/JavaScriptで全て実装されていて、いわゆるハイブリッドアプリケーションになっています。

特徴は以下のとおり。

• Atom ShellとAtom Coreによるデスクトップアプリケーションである
• アプリケーション自体はHTML/CSS/JavaScriptで実装されている
• 開発はGitHub上で行われている

Atom Shellについて

Atom ShellはChromeのオープンソースプロジェクトであるChromiumと、Node.jsのForkプロジェクトであるio.js（もともはNode.jsを利用していたが、最近変わった）で構成された、ネイティブアプリケーションプラットフォームです。 Atom Shellの概念図は以下のとおり。

BrowserというところがChromiumをベースにした部分であり、ネイティブアプリに必要なメニュー構築やダイアログ生成などを担当しています。また、Node.jsにてBrowserのネイティブAPIにアクセスできるインターフェースが用意されています。Renderer部分は、実際にアプリケーションの画面を描画したり、ロジックを組み込む部分であり、通常のWebアプリケーションと同じく、HTML、CSS、JavaScriptで実装することができます。JavaScriptについては、こちらもNode.jsが利用できます。

Atom Coreについて

Atom Shellの上にAtom Coreというメインのアプリケーションが存在します。Atom CoreはPackageというかたちで様々な機能を追加することができます。また、見た目についても、Themeというかたちで、様々に変更することが可能になっています。

PackageやThemeの開発を含めたAtomの開発は、GitHub上で行われていて、だれでも自由にCommitすることができます。

ThemeでどのようにCSSが利用されているのか

さて、ここから、セッションの本題に入っていきます。

HEADエレメント

まずは、<head>エレメントの中をご紹介します。このソースはAtom CoreのベースとなるHTMLファイルを簡略化したものです。

<html>
	<head>
		
		<style source-path="bootstrap.less"></style>
		<style source-path="atom.less"></style>
		
		<style source-path="tree-view.less" priority="0"></style>
		<style source-path="tabs.less" priority="0"></style>
		<style source-path="status-bar.less" priority="0"></style>
		<!-- Many many more packages -->
		
		<style source-path="ui-theme.less" priority="1"></style>
		
		<style source-path=".atom/style.less" priority="2"></style>

	</head>
	<body></body>
</html>

はじめに、bootstrap.less（normalize.css含む）を読み込み、次にCoreスタイルであるatom.less、Packageのlessファイル（tree-view.less等）を読み込み、そして、Themeを構成するui-styles.lessを読み込みます。実際には、それぞれのLESSファイルはCSSにプロセスされて挿入されることになります。

これは、Atom Editorの画面上でインスペクタ（開発者コンソール）を表示させて確認したところです。CSSのコードが挿入されていることがわかると思います。

UI Theme と Syntax Theme

次に、Themeについて詳しく見ていきます。Themeには、UIとSyntaxの2つがあります。UI Themeはアプリ全体のスタイルを規定し、Syntax Themeはエディタ部分のスタイルやコードのシンタックスハイライトなどを規定しています。

Themeのマークアップサンプルを見てみましょう。

<html>
	<head>
		<style source-path="ui-theme.less" priority="1"></style>
	</head>
	<body>

		<ol class="tree-view"></ol>
		<ul class="tab-bar"></ul>
		<status-bar></status-bar>
		
		<atom-text-editor>
			#shadow-root ----
			<style source-path="syntax-theme.less"></style>
			<div class="gutter"></div>
			<div class="lines"></div>
			#end-of-shadow-root ---
		</atom-text-editor>

	</body>
</html>

ui-theme.lessとしてUI ThemeのLESSファイルを読み込みます。そして、UIに必要なパーツを配置していきます。このサンプルでは、tree-view、tab-bar、status-bar、atom-text-editorというパーツが記載していますが、実際にはもっとたくさんのパーツがあります。

そして、atom-text-editorエレメントの中では、エディタ部分を構成するためのパーツと、コードのシンタックスハイライトのためのSyntax ThemeのLESSファイルを読み込んでいます。

atom-text-editorエレメントはWeb Componentsの技術が利用されています。そのため、実際にはこのように#shadow-rootが挿入されます。Web Componentsを利用することで、UI ThemeとSyntax Themeを明確に分ける構造になっています。これによって、スタイルの衝突やクラス名の衝突を避けることができます。

shadow-rootは実際には、以下のように挿入されます。

ONE Theme

では、ONE Themeというテーマを例に、実際のThemeファイルの中身を少し見てみます。ONE Themeのソースコードはこちら（https://github.com/atom/one-dark-ui）で確認できます。

Atom Editorはテーマを読み込む際に、index.lessというファイルを最初に参照します。index.lessは@importで関係するスタイルファイルを順次読み込んでいきます。いわゆる、ヘッダーファイルのような役割を担っています。この例ではフラットに記載されていますが、書き方は自由です。

// Atom UI Theme: One

@import (reference) "styles/ui-variables";
@import (reference) "styles/ui-mixins";
@import (reference) "octicon-mixins";

@import "styles/atom";
@import "styles/badges";
@import "styles/buttons";
@import "styles/editor";
@import "styles/git";
@import "styles/lists";
@import "styles/messages";
@import "styles/nav";
@import "styles/overlays";
@import "styles/panels";
@import "styles/panes";
@import "styles/progress";
@import "styles/tabs";
@import "styles/text";
@import "styles/tooltips";
@import "styles/tree-view";
@import "styles/utilities";

@import "styles/settings";
@import "styles/core";

@import "styles/_deprecated";

スタイルファイルの中で注目すべきところは、カラーコードがハードコードされているわけではなく、全て変数として切りだされていることです。以下の例であれば、@tab-text-colorなどがそれに当たります。

:
 :

  .tab {
    position: relative;
    top: @tab-top-padding;
    max-width: @tab-max-width;
    min-width: @tab-min-width;
    height: @tab-height;
    line-height: @tab-height;
    padding: 0;
    margin: 0;
    color: @tab-text-color;
    background: @tab-background-color;
    border-right: @tab-border;
    opacity: @tab-inactive-transparency;
    transition: opacity .3s;
 :
 :

切り出されたカラーコードは、ui-variables.lessというファイルにまとめて記述されています。

:
 :

// Component Colors -------------------------------------

@app-background-color:             darken(@level-3-color, 2%);

@tree-view-background-color:       @level-3-color;
@tree-view-border-color:           @base-border-color;

@tab-background-color:             @level-3-color;
@tab-background-color-active:      @level-2-color;
@tab-bar-background-color:         @level-3-color;
@tab-bar-border-color:             @base-border-color;
@tab-border-color:                 @base-border-color;

 :
 :

これらの色情報同士は互いに連携。ある１箇所を変更すると関係する箇所が合わせて変更されると共に、色同士の関係性を見て、一体感のある色調になるように自動的に調整されるようになっています。

@import "syntax-variables"

 :
 :

@ui-a:       hsl(252, 11%, 18%); // fallback
@ui-a:       @syntax-background-color;

// Goal: use @syntax-background-color if it's dark enough, otherwise use same hue but stay dark
// The light up by 100% is done to trick contrast() into picking one of 2 dark colors
@ui-a-h:     hue(@ui-a);
@ui-a-s:     min( saturation(@ui-a), 12%);
@ui-a-l:     luma(@ui-a) + 100%; // (1) light up
@ui-a-light: hsl(@ui-a-h, @ui-a-s, @ui-a-l); // (2) flashed color
@ui-a-color: contrast(@ui-a-light, @ui-a, hsl(@ui-a-h, @ui-a-s, 24%) ); // (3) use @ui-a if darker than 24%

 :
 :

また、ui-variables.lessでは、Atom Editorで標準定義されているシンタックスハイライトのための色情報を、syntax-variablesから読み込むことで、@syntax-background-colorという変数をこのテーマのシンタックスハイライトカラーとして利用しています。

Style Guide

Atom Editorでは、だれでも、EditorのThemeを作ることが可能です。新しく作ってもいいし、既存のThemeをフォークしても構いません。Themeを新作る際の便利な機能として、Style GuideというPackageが標準搭載されています。

Style Guideを利用することで、Themeの中で規定されている色情報やClassの定義など全てを、視覚的にリアルタイムに確認することができます。

<起動方法> Packages > StyleGuide > Show

Themeの作成やカスタマイズにはなくてはならないツールです。

Atom Editorの悪い部分

冒頭に紹介したCSS-Tricksのブログでは、よい点だけではなく、問題点なども合わせて取り上げられているため、とても参考になります。Atom Editorについても、それに習って、あえて悪い部分を取り上げてみます。

1. どこにソースファイルがあるか分からない

Atom Editorのインスペクタを表示するとわかると思いますが、CSSそのものへのリンクはありません。これは、LESSを動的にCSSに変換しているので、そもそもCSSファイルが存在しないためです。

また、以下のように、同じセレクタが複数存在するところがあります。それぞれPackageとThemeで定義されているのですが、どちらがどちらに定義されているのか、インスペクタを見ただけではわかりません。これは、Source mapを使えば解決できるかもしれませんが、現在のAtom Editorには含まれていません。

2. CSSのネストが深い

上記画像を見ると、Classのネストが3階層になっている事がわかると思います。このように、ネストが深い部分が多々あります。そのため、特定の属性を上書きしたい場合などは、Classのセレクタをネストの数だけ記載する必要が出てきます。

これは、セレクタを以下のように記載することで解決することができます。

// SUIT ----

.Tabs {}
.Tabs-item {}
.Tabs-title {
	color: white;
}

// Benefit ----

.Tabs-title {
	color: red;

}

このようにセレクタを記載することで、以下の様な利点が生まれます。

• シングルClassでその値を上書きすることができる（上記Benefit参照）
• 名前空間を最小限にできるため、上位Classの変更に対する影響が下位Classに及ばない
• マークアップの際にClassのネストの順番を意識しなくてよくなる
• Classの検索性がよくなる

3. Atom Editor Version 1.0ローンチ間近…

ではなぜ、Atom EditorでこのようなSUIT CSSやBEM CSSなどの設計ルールを取り入れないのか。実際に、GitHubのIssueでもそのような問い合わせがきています。

取り入れない理由は、Atom Editor Version 1.0のローンチが間近に迫っており、近々仕様凍結が予定されているためです。仕様が凍結されると、Classの命名規則含めてAPI仕様の大幅な変更ができなくなります。そのため、SUITやBEMなどの導入はVersion 2.0に向けて行う必要が出てきているのです。

Atom Editorの未来

Atom Editorに将来実装したい機能の１つとして、UIテーマのコントラストを周辺光に合わせて自動的に調整する機能が考えられています。

例えば、部屋の明かりが暗い時は、このように見やすいThemeですが…

部屋が明るくなると、画面への光の映り込みが起こり、見難くなりますよね。

これを解決したいのです。

周辺光に合わせたUIテーマの自動調整は、W3Cで標準化が進んでいるlight-level MediaQueryを利用することで、実現することができると考えています。

// default
body {
	color: hsl(0,0%,70%);
}

// gets dark
@media {light-level: dim} {
	body {
		color: hsl(0,0%,48%);
	}
}

// gets bright
@media {light-level: washed} {
	body {
		color: hsl(0,0%,100%);
	}
}

// other pattern
@media {light-level: washed}{
	body {
	-webkit-filter: contrast(1,25) brightness(2);
	}

}

このように記載することで、デバイスに搭載されている光学センサで周辺光を測定し、その値に応じてbodyエレメントの明るさを調整することができます。

また、明るくなった場合の別の調整手段として（上記other pattern参照）、contrastとbrightnessを利用して、画面全体のコントラストや明るさを一気に調整することもできます。しかしながら、これはパフォーマンスがよくない可能性もあるので、実装する際には注意が必要です。

まとめ

Simurai氏のセッションは、Atom Editorが『なぜhackable text editorなのか？』を、わかりやすく伝える面白い内容でした。興味を持たれた方は、是非、Atom Editorを自分色にカスタマイズしてみてください！

もっと詳しくAtom Editorについて聞きたい！知りたい！という方は、Twitterなどでご本人に質問してみるとよいでしょう。

@simurai – https://twitter.com/simurai

Frontrend Conference特集はまだまだ続きます！

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。

この記事は、「Frontrend Conference The Final」の基調講演「Pragmatic Front-end Developer: From Artisan to Expert」についてのレポートです。

登壇されていたのはリッチメディアの斉藤祐也さん。HTML5 Experts.jpでも、No.10のエキスパートとして何度もご執筆いただいているので、ご存じの方も多いかと思います。

この講演タイトルは、アンドリュー・ハント氏の著作「The Pragmatic Programmer」をオマージュしたとのこと。「Pragmatic」というのは「実践的」という意味の単語で、フロントエンドという広大な分野における道標となるような、実践的なノウハウをたくさん紹介していました。

この記事は、斉藤さんの講演を聴講した筆者が、自分なりの言葉で内容をまとめてみたものになります（斉藤さんの言葉をそのまま書き起こしたわけではありません）。この講演のスライドはSpeaker Deckにて公開中です。そちらも合わせてご覧いただければ、より理解が深まるかと思います。

キーワードは「CARE」！

この講演におけるキーワードは、以下のトピックの頭文字を取って「CARE」。講演自体も、以下のトピックの順番に沿って進められていましたので、この記事もその流れに沿って書いていきたいと思います。

• Be Collaborative (問題は人と人の間にある)
• Be Adaptive (変化に対して寛容に)
• Be Responsible (作ったものに対して責任を持つ)
• Be (an) Expert (知ることに対して貪欲に)

Be Collaborative (問題は人と人の間にある)

HTML, CSS, JavaScriptといった技術は、専門家でなくても書けてしまうという気軽さがある代わりに、メンテナンス性に優れているとは言えません。ただ、そうしたテクノロジーは日進月歩です。メンテナンス性に欠ける、という弱点を補足すべく、様々な進化を続けています。そうした状況においては、コラボレーションにおける問題はテクノロジーそのものではなく、人と人の間にあるのです。

例えばコラボレーションを円滑に行うためには、コードスタイルのガイドラインが必要です。理想は、一つのコードベース上のコードは、一人の人間がタイプしたかのように見えること。そうした理想を追求するためのスタイルガイドとして、以下のようなことが挙げられます。

JavaScriptのコードスタイルガイド

JavaScriptのコードスタイルガイドについては、以下を参照するとよいでしょう。

• idiomatic.js
• jQuery Core Style Guidline
• Airbnb JavaScript Style Guide

CSSのコードスタイルガイド

CSSのコードスタイルガイドは、以下に挙げられたことが参考になります。これらのうち、どのガイドラインが優れているか、は問うべきものではありません。「自分たちのプロジェクトに、スタイルガイドが存在する」ということがまずは大事なのです（実際、セッション参加者に「コードスタイルガイドラインをお持ちの方」を聞いたら、1割程度だったそうです）。もしないのなら、これらを元に自分たちなりのガイドラインを定義するとよいでしょう。

• idiomatic.css
• CSS Guidelines
• Sass Guidelines
• Code Guide

コードスタイルチェックを自動化するツールたち

上記のようなコードスタイルガイドラインに準拠しているかどうかを、人間が目で見てチェックするのは容易ではありませんし、時間の無駄です。「貴重なレビューの時間を、コードスタイルチェックに費やしてはいけない」という斉藤さんの言葉は、非常に重みがありました。

• EditorConfig
• JSCS
• CSS LINT
• CSScomb

包括的なスタイルガイド

また様々な企業が、自分たちが使っている包括的なスタイルガイドを公開しています。上記のコードスタイルガイドよりもより粒度が粗く、実際のユースケースに沿った形で定義されていることも多いので、参考にするとよいでしょう。

• GitHub styleguide
• Starbucks style guide
• MailChimp Style Guide
• Website Style Guide Resources

ドキュメンテーションのためのツール

また開発者であれば、「ドキュメントは嘘をつく」という言葉には、深く同意せざるを得ないでしょう。 日々変更されていくソースコードに対して、ドキュメントはどうしても更新が追いつかないという状況に陥りがちです。以下のツールは、CSSのドキュメンテーションツールのうち代表的なものです。これらのツールを使えば、コードとドキュメントが、常に同期されているという理想的な状況を目指すことができます。

• KSS
• KSS Node
• hologram

プロトタイピングに役立つツール

また、コラボレーションを行う上で重要なのは「実際に見えるもの、動くものに対しての意見は言いやすい」ということです。貴重な時間をムダにしないためにも、まずはさっさと動くプロトタイプを作ってしまい、それを元に議論を進めましょう。

斉藤さんがオススメする「プロトタイピングに役立つツール」は以下になります。

• BrowserSync・・・コードとブラウザ、もしくは異なるデバイス上で実行中のブラウザの状態を同期してくれます。開発時の結果確認が非常に迅速になるだけではなく、デバッグやプロトタイピングの用途にも活躍します。
• JS Bin・・・HTML/CSS/JavaScriptのコードをWebブラウザ上で記述し、共有できるサービスです。
• Google Chrome Canary・・・言わずと知れた、Google Chromeの最新＆安定性が保証されていないバージョン。斉藤さんによれば、「打ち合わせ中、ブラウザでダイレクトにお客様のご要望をコーディングしていき、その反応を得るのはとても楽しい時間」とのこと。

Be Adaptive(変化に対して寛容に)

様々なスクリーンサイズやデバイス上でWebサイトが利用されることは既に当たり前で、プログレッシブ・エンハンスメントの重要性はこれまでも何度も取り沙汰されてきました。

斉藤さんはプログレッシブ・エンハンスメントの考え方について、エスカレーターの例えを用いて説明されていました（とてもわかりやすい！）。

エスカレーターは、例え止まってしまったとしても階段として機能するため、「違う階に人を運ぶ」という機能自体が失われることはありません。

一方エレベーターは、止まってしまうとただの箱。この違いが、プログレッシブ・エンハンスメントを実践しているサイトとそうでないサイトの差に近いものがあります。

なぜこれほどまでにプログレッシブ・エンハンスメントが重要かというと、Webは（ある形の決まった）プラットフォームではなく、継続して変化し続けているあやふやなものだからです。ブラウザも、デバイスも、ネットワークも、将来的には全く違ったものになっているかもしれないのです。

この変化し続けている環境では、しっかりと自分の哲学を持ってディテールにこだわりを持ちつつも、前提条件が変わった時にそのこだわりを潔く捨て去ることが、優秀なエンジニアには求められているのです。

Be Responsible(作ったものに対して責任を持つ)

そして、これまで紹介してきた様々なスタイルガイド、ツール、プログレッシブ・エンハンスメントといったものは、技術者が自分の作ったものに対して責任を持つために必要不可欠なものです。

Webという常に進化し続ける環境において堅牢なプロダクトを作ること、そしてその堅牢さに常に疑問を抱き、「もし」をしつこいくらい重ねること。それらを手助けするのが上記のツールだというわけです。

また、プロダクトの堅牢さという点では、パフォーマンスは非常に重要です。例えば著名なMVCフレームワークがパフォーマンスに与える影響を調べたこちらの記事によれば、初回ロードにかかる時間が1,000msを下回ったものはなかったそうです。

Webアプリのパフォーマンス改善に関する取り組みは、様々なところで行われていて、例えばEmber.jsはfastbootという仕組みを提唱していたり、Flipboardが採用したReact-Canvasは、ReactによってDOMではなくCanvasにレンダリングするという仕組みで、ネイティブと比べても遜色ないくらい高速な描画を実現しているそうです（ただし、当然ながらアクセシビリティは一切考慮されておらず、それが議論を呼んでいるとのこと）。

Be (an) Expert(知ることに対して貪欲に)

「CARE」の最後は、「エキスパートになろう」ということ（HTML5 Experts.jpとしては、応援すべきフレーズとしか言いようがありません）。以下の様なことを普段から心がけて常に知識を取り込み、エキスパートを目指しましょう。

• 「できない」と言わない。オプションを提示する。
• 壊れ窓の中で仕事をしない
• 「十分」がいつなのかを知る
• 知識を増やすための時間を定常的に設ける

フロントエンドはこれからも重要であり続ける！

講演の最後に、斉藤さんは「フロントエンドはこれからもWebに必要とされるのか？」という問いかけに対して「YES!」と力強く答えていました。

Webという環境は変化しますし、ビジネスの世界もめまぐるしく動いている中、フロントエンド技術者の仕事もどんどん変化していくことは避けられません。ですが、「フロントエンド」という分野の重要性そのものは、これからも高まり続けることでしょう。

フロントエンドはどこにもいかない！

イベント動画

イベントの模様はYoutubeで公開されています。よろしければ、ご覧ください。