今年もHTML5 Conference 2017の展示ブースでは、私ことDJ KATOの特別ラジオをお届けしていました。今回はビジネス・アーキテクツ太田良典さんとサイバーエージェント原一成さんをゲストに迎え、「UIデザインとアクセシビリティ」テーマに語っていただきました。その再現レポートをお届けします。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、どんな講演内容だったのか教えてください

「ビジネス・アーキテクツの太田です。普段はWebアクセシビリティ関連の活動を主に行っています。『多様なユーザーニーズに応えるフロントエンドデザインパターン』というタイトルで講演させていただきました。よろしくお願いいたします」

「サイバーエージェントの原です。アメブロのフロントエンド開発を中心に行っています。『“モダン” ウェブアプリケーション ～アメブロ5ヶ年計画～』という講演タイトルで、アメブロの “モダン化” 実例に沿った考え方や技術採用事例、今後の展望などをお話しました」

「お二人とも先ほど同じ時間に講演されてきたんですよね。どちらかのお話を聞いた人は、どちらかが聞けなかったと思うので、どのような話をされたか教えていただけますか」

「私は、11月4日発売の『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』という書籍で紹介されている、アクセシビリティに配慮した実装手法について、例を挙げて紹介しました」

「どのような実例でご説明されたのでしょうか？」

「先ほどのセッションではサイトでの操作など、使いやすくするためにはどうするかという話をしました。例えば、商品のリストを値段の高い順や安い順に並べたり、最新順に並び替えるなどの機能も、基本的な要素を使ってマークアップしましょうという話ですね。絞り込みの機能を選択するのは高い順・低い順・古い順・新しい順が多いのですが、それは4個の中から1つを選ぶ機能なので、ラジオボタンで実装すればいいとか。

よくある問題は見た目がきれいになるからと、ラジオボタンじゃなくて<span>とか<div>で実装して、JavaScriptでクリックイベントをつけて操作できるようにするとか。それは、ラジオボタンで実装することによってキーボード操作であっても使いやすくすることができます。でもソフトキーボードでちゃんと使えるのか、スクリーンリーダーでアクセスしたときにちゃんと読まれるのかなど、いろんな問題があるわけです。なので、基本的にはちゃんと機能に合った要素を使って、見た目は後からがんばりましょうという話ですね」

「先に知っておけば、そういう落とし穴には落ちないということですね」

「HTMLをやってる人なら誰でも知ってるはずなんですけど、なぜか<div>とか<span>を使ってしまうんですよね。知っていることと実践できているかというのは別なんです」

「そうなってしまうのは、楽だからなんでしょうか」

「というか、『見た目から入ってしまう』からそうなるんですよね。見た目から入ると『枠で囲まれているから<div>かな』という考え方になりがち。後から結構スクリプトでできちゃうので、それなりに動くものができるんですよね。ただ、それがどんな環境でも使えるかというと、結構使えないことがあるのが問題です」

「そういったことをいろいろご紹介されていたんですね。チェックボックス以外のトピックも聞いてみたいです」

「リストや見出しをちゃんと使うことですね。あとJavaScriptやXHRを使ったパフォーマンス改善やアクセシビリティの話を中心にしていました。

アクセシビリティは『JavaScriptをできるだけ使うな』という議論になることが結構多いんです。でも、今普及してるUIはJavaScriptで動かしていることが多いのに、そんなこと言われても困るんですよね。今回ご紹介してる本ではこうすればできるという技法を紹介しています」

「ありがたいですよね。僕もJavaScriptを使いまくりなんですけど、実際のサービスを作る上ではやっぱり使わざるを得ない。さらに、ネイティブアプリとの差をなくしていったり、使いやすさを向上させるには必要な技法です。ピンク本と呼ばれる「デザイニング Web アクセシビリティ」という本があるんですが、毎週チームで読み会をしています」

「そのピンク本、ありがたいことに私の著書なんです(笑)」

「うちの会社にもあります。みんなは読んでいる本なんですけど、僕はどっちかっていうとエンジニアというよりディレクター寄りということもあって、まだ読んでいませんでした。すみません…」

「ディレクターさんにもすごくいい本ですよ」

「というか、ディレクターさんにもぜひ読んでいただきたいと思って書いた本です(笑)」

「なるほど！読みます！」

「実装だけじゃなくて、その上流から踏まえていきましょう、ということも結構書いているので、ぜひ読んでください」

「さっきのサイト制作の話に戻るんですけど、見た目から入っちゃうことが結構多くて。特にビジネスで評価する人って、この見た目がかっこいいとかから入っていきがちなんですよね」

「見た目と動きだけでしか評価できない人が多いという問題もありますね。見た目と動きがちゃんとしてればOKになってしまうことも多いんですよ」

「例えばディレクターがアクセシビリティを知らなくて、スクリーンリーダーなどの存在を知らなかったら、それだけで話が通じなくなりますよね」

「そうですね。それを解消するためにも、ぜひ！」

「まずこれを読むことで、関係者全員のしなくてもいい紛争が減ると」

モダンなウェブとアクセシビリティは両立できますか？

「原さんはモダンなウェブというテーマで講演されていましたが、アクセシビリティと両立するのは難しくないんですか？」

「難しくはないんですけど、ワークフローの中に組み込むのが結構大変ですね。プロジェクトは企画から始まって、デザインを作って…というように、見た目が前提なフローが多いので、どうしてもコードがわかる人はフロントエンドエンジニアくらいになるんですよ。評価できる人も」

「自然と優先度が下がっちゃう、というかんじですね」

「そうなんです。先程も言ったように『コードを知らない』って方もいるので、ピンク本は『JavaScript使うな』とは書いていないので、その辺もありがたいです」

「そういうことですか！」

「昔ながらのアクセシビリティをやってる人だと、『JavaScriptは使うな！』と言っちゃう人もいるんですよね。現場ではそう言われても困るので、なんとかしたいって思ってたんです。今回の本はそういう内容がたくさん書かれているので、いいなと思っているんですよね」

「極端ですけど例えば『危険だから家から出るな』みたいな話になっているんですかね」

「そうそう。何かあった時に『これとこれとこれを準備して』とか『こういうことに気をつけて』というのを示してくれるかんじなんです」

ところで、普段はどんなお仕事しているんですか？

「話は変わるんですけど、太田さんは普段どんなお仕事されてるんでしょうか？」

「ビジネス・アーキテクツという会社で、Webの仕事をしています。主に大きな会社のWebサイトを受託で作ることが多いです」

「企業の公式Webサイトですね」

「そうなんです。グローバル展開している日本の大手企業が多いのですが、そうした企業はアクセシビリティのガイドラインを持っていて、各国に配布したりしてるんですよね。各国にもそれぞれサテライトサイトがあって、全部統一させようと取り組んでいます。そういうアクセシビリティのデザインガイドラインの配布や取り組みに対して、お手伝いをしています。ひと言で言うと、Web制作ですけど」

「ひと言だとそうなんですけど、大変そうというか、慎重にやってかないと…。なんか、あまり軽いノリで作れないサイトってかんじですね」

「重すぎるノリっていうのも問題で、これやるなって言いすぎてもガイドライン無視されるだけなので、やっぱり現場で使えるようにしていかないと。実際に使えるものを作って、かつ運用できるようにしていくということがすごく大事なんですね」

「そうすると、基本のWebだけではなく、モダンな開発手法も知らないといけないですね」

「最近だとモバイル用のページをレスポンシブで作るのが当たり前になっていると思うのですが、そういうところも考えないといけないことがありますね」

「スマートフォンのモバイル用のページのことや、PC用ページではどうかとか、デスクトップのリーダーではどうかというのも書いてあって便利です」

「原さんは、どんなお仕事をされているのですか？」

「私は完全に開発者で、2004年からずっとアメーバブログを作っています」

「長いですね！」

「2015年にリニューアルをしていますが、サービスの歴史も長いですね。主にフロントエンドを担当しています」

「歴史が長いと今までに積み上げてきたものも多いと思います。社内で設計が大きく変わったりすると、かなり大変だと思いますが」

「その辺はエンジニアと協力しながらやっていますね。iOSならiOSの、AndroidならAndroidのエコシステムっていうか開発環境と作り方の基本があるんですけど、その上で他の人と会話しながら、モダン、モダンって言いながら開発してます。閉じこもった自分たちだけのライブラリばかりでは、存続が危うくなると思うので」

「お二人ともなんというか共通するところがあるっていうか、戦っているポイントが結構似ているかんじがします」

「かなり」

「そうですね」

お二人の情報収集や勉強方法を聞かせてください

「お二人はどのように情報収集や勉強されているんですか？」

「今まさに勉強しているつもりです」

「そうそう。かなり勉強してます(笑)」

「気がついたら置いていかれてた…っていうのは一番避けたいのですが、そのためにどんなことをしたらいいのでしょうか。ニュースサイトを見るとか？」

「それもありますが、周りの人と会話をすることも大事なんじゃないかと。最先端の技術者たちとコミュニケーションをとったり、彼らがTwitterなどで何をシェアしているのかを見ることで、どういうものが流行っているかを知ったりすることが多いですね」

「僕も一番簡単な情報収集はTwitterですね。フォローしておいて、その人がリツイートしているものを見るだけでも参考になります。あと、海外の情報も重要なので、英語が読めるだけでも大分可能性は広がります。ちょっと時間差はあるかもしれませんが、日本語に訳してくれる人をフォローするという手もありますね」

「Twitterはすごい情報数があふれているので、普段あまり使ってないんですけど…。どうやって情報の絞り込みをするんですか？」

「もちろん、全部を読むわけではないですよ」

「技術系のカンファレンスで気になったものをフォローしているので、そこからとか」

「良質なツイートをしている人が発信している情報を集めて、どんどんその濃度を上げていくみたいなかんじなんですね」

「あとは情報を発信している人のところに実際に行ってみるとか。そういう会社に入っちゃうというのもありますね」

「なるほど！」

「簡単に希望したところに行けるかはわからないですけど」

「そういう意味では、サイバーエージェントさんは大変いい環境ですよね」

「うちは情報が自然に入ってくる環境なので、勉強する必要がないっていうか。極論ですけどね(笑)」

「自然にっていうのがすごいですよね。周りの人との雑談がなんかマークアップの話になるとか？」

「ちょっと気持ち悪いかもしれないですね、普通の人からすると(笑)。技術に興味がある人が集まっている場所というか」

「でも、マークアップの話で盛り上がれるってすごく楽しいですよね。いや、『それ変態だ』って言われそうですけど(笑)」

アクセシブルなサイト設計・制作について教えてください

「簡単なアプリケーションだったら自分で作ったりもするんですけど、実際に開発始めてみると<div>とか<section>とか、途中で<h3>や<h4>がだんだん適当になってくんです。100行超えてくると『あれ？もともとどんなかんじに作りたかったんだっけ』というかんじになって、全体のことがあやふやになってくるんですけど、どうすればいいんでしょうか」

「それはいい質問だと思いますね！早い段階から見た目を気にして、その段階で増やそうと考えちゃってるんですよね」

「はい。で、書きながら実行してるんですよ」

「それは自然ではあるんですよね。悪いことではないんですが、基本的にオススメなのは、まずCSSを一切適用しない状態でHTMLだけで作ってしまうこと。結構しっかりした構造が作れると思います」

「完全に素のやつですよね」

「さらに言うと、見出しから作っていくとか。それがマークダウンなんですが、逆に難しいかな」

「以前僕が経験したものだと、先にデザインが決まり、デザインカンプが上がってきて、スライスしてCSSをあてる。で、インタラクションとかをJavaScriptでやるという順番でした。ちゃんと考えたつもりなのに、だんだん破綻していくんですよね。いきなりフロートからやるとか、順番がおかしいとは思ってたんですけど(笑)」

「もしかすると、デザイナーさんもあまり整理できてないのかもしれないですね。うちではコンポーネント思考で、デザインから作っています。Webコンテンツをコンポーネントっていう単位で分割するんですよ。例えば見出しなら見出し、本文なら本文、リストならリストみたいなパーツに分割してデザインしてくんです。

それを組み合わせてWebページを作るというシステマティックなやり方をしています。ページごとにデザインするのではなく、パーツごとにデザインしたものを組み合わせてページを作るという考え方をデザインの段階からやっているんです」

「最初はみんな紙ベースというか、ペライチみたいなデザインで始めることが多いんですよね。紙って自由度が高いけど、文字や画像などのコンテンツをバラバラにすることはできなかったり、うまく区切れなかったりとか、Webとは考え方ややり方が違いますよね」

「逆にWebのやり方がわかっているデザイナーさんだと、『これは<h1>で』とか言ってくれたりするんですよ」

「あとは自分たちで共通部分を見つけてコンポーネント化していくとか」

サイトの構造やレイアウトデザイン、昔と今ではどう変わってますか？

「以前、コーディングは全然やらない人で完全にデザインだけやっている外部の人が、『こんな感じでよろしく』って送ってきたデザインが最悪だったことがあります。一方で、フロントエンジニア兼デザイナーをやっている人とやった時はすごくて、まずデザインの前にきちんと要件をはっきりさせてくれました。自分がちゃんと考えきれてなかったサイトの構造やボタンの位置にツッコミを入れてくれたりとか。みんながそれできるかっていうと厳しいですけど」

「今日登壇してる方たちもみんな通っている道ですね(笑)。めちゃくちゃのところからスタートして、だんだん良くなっていくという」

「それはあると思いますね。我々なんかの世代だとHTML3.2の時代からやっている人もいるので。以前はテーブルレイアウトというのがあって…」

「あー知ってます！昔やってましたよ、それ。一番最初にWebサイト作ったときに全部テーブルやりましたね」

「構造も何もあったもんじゃない(笑)」

「完全に見た目だけですよね。最近入社してきた若手なんかはテーブルレイアウト知らない世代でしたけど」

「ある意味うらやましいですね(笑)」

「昔はありだったんでしょうか」

「あるかなしかっていうと、なしだったんですけど。仕方がなかったっていうか」

「あれはフロートがなかったからとかそういうことだったんでしょうか」

「フロートがいつからあったかというのは難しい議論なんですけど、昔はブラウザのCSS周りの実装がボロボロだった時があって、IEでフロートすると横マージンが2倍になるとかありましたね」

「まぁ環境が整ってなかったというかんじですよね。だから一概にさっきの話も悪いとは言えないというか」

「Web標準が流行り出して、ブラウザの実装が統一されてきたのも、もう10年前くらいですね」

「モバイルが出てきてWebkitベースで確認できるようになって…」

「それ以前はもうぐっちゃぐちゃですよね」

「昔はできたデザインとマークアップした結果を重ねて、透過して1ピクセルもずれちゃいけないみたいな」

「ピクセルパーフェクトってやつですね！」

「聞いたことあります」

「昔は『全部のブラウザで同じ見た目にならないといけない』って時代があったんですよ。でも今はそういう時代じゃないですね、『デバイスによってちょっと違いますよね』ってのが当たり前になっているので」

「今はデバイスの種類がたくさんあるので、ピクセルよりも文字サイズはremとか、高さも%じゃなくてvwとか使うんでしょうか」

「状況によりますよね、使うべきときは使います。ちなみにそういう単位をどういうときにどれを使うのかという議論も、『インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン』に書いてありますので、もしご興味があればぜひ！」

「ぜひ、勉強します！」

「CSSが一番難しいですよね」

「同じことを実現する方法が結構いくつもあって、でもやり方によって結果がかなり違ってくるとか」

「僕CSS書いたら1万行くらいいってしまったことがあって…。さすがにディレクターの人に『俺でも3分の1にはできるぞ、書き方おかしい！っていうか、全部に対してCSS書いてるじゃん』って言われたことがあるんです。その辺のベストプラクティスもあるんでしょうか」

「今はセレクターの値の設定やファイルの指定とか、いろいろな方法が考えられてます」

「CSSについても書いてありますか？」

「そこまで深くはないかもしれないですけど、それなりにCSSについての議論は書いてあります。楽しい本ですよ」

「ありがとうございます！個人的にはすっきりしてきました。なんかもやもやしてたことに明確に答えが返ってきて、なんだか気持ちいいです」

「そうですよね。他の人ととりとめない話をすることがすごく勉強になるみたいなこと、結構あると思うんですよ」

「いろんなカンファレンスありますが、純粋に技術の話できるというのは面白かったなあと思います」

UIを考える時に一番気をつけるべきことは何ですか？

「そろそろまとめというか『オチ』に入っていきたいので、最後に質問をさせていただきます。UIを考える時に一番気をつけないといけないことって何でしょうか」

「ユーザーのことを考えるというのが一番重要だと思います。これでユーザーが実際に使えるのか、どんなユーザーがいてどんな環境でどう使うのかを意識することが大事なことなんじゃないでしょうか」

「僕もユーザーですね。いろんなユーザーがいるということを、いかに自分の中で学ぶかということだと思います。一番いいのは、いろんなサービス使ってみたりして、自分がいろんなユーザーになれることですね。例えば、日本だと回線は速いけど海外だと遅いとか、性能の低いデバイスしか売ってないとか。こんな良い端末でこんないい回線使っている人は世界中にはそんなにいないですよと。そういったことを想像して、自分がユーザーとして変化できることも必要だと思っています」

「そのとおりですね！今日はとても勉強になりました。本当にありがとうございました！」

「ありがとうございました！」

「行取り」あるいは「バーティカルリズム」とは、要素の配置に一定のリズムを取り入れることで、デザイン上の安定感や、可読性の向上などの効果が見込るデザイン手法です。通常は、本文の行の高さをリズムの単位として、要素間の余白を調整します。ノートの罫線や、原稿用紙をイメージするとわかりやすいと思います。

上の例のように、CSSでline-heightやmarginを適切に設定すれば実現可能ですが、メンテナンスが煩雑になる、レスポンシブにするのが難しい、見出しが複数行になるとうまくいかない、などの課題が残ります。

現在W3Cでは、この問題を改善するために、line-height-stepという新しいプロパティを議論しています。まだ異論や技術的課題が残っていますが、Chrome、Edge、Safariは賛同しており、Chromeでは試験運用機能として実装もされています。この記事では、このプロパティを使って、バーティカルリズムを実装する方法について解説します。

二つのスタイル：強いリズムと弱いリズム

まずは、どこにどのように適用するかを考えます。「バーティカルリズム」にもメリットとデメリットがあります。メリットとデメリットを理解して、適切に適用する方法を考えてみましょう。

一つ目のメリットは、行や要素が一定の間隔を持つことで、デザイン上の安定感が生まれることです。規則的に並んでいるデザインは、洗練、安定、安心、といった印象を与えます。

二つ目のメリットは、脳が一定のリズムをパターン認識することで、可読性を上げることです。目線が次の行頭に移動する時は、可読性が一番妨げられる時でもあります。脳が次の行頭位置を予測することで、目線の移動を助け、より早く、より楽に読めることで、内容の理解力も高まるとされています。

残念ながら、デメリットもあります。一つ目は、スペースを消費することです。余白を広げて調整するため、適用しない場合と比べて、より広いスペースが必要になります。モバイルでは画面の大きさが限られているため、本文の行の高さの半分をリズムの単位にするなどの工夫もあるようです。

デメリットの二つ目は、余白が一定でなくなることです。これはちょっとわかりにくいので、例を挙げて説明します。

画像や表、引用文、コード、コラムなど、大き目のブロックが入った場合を考えてみます。「バーティカルリズム」を適用するなら、これらのブロックの高さを本文行の高さの整数倍に揃えることになります。雑誌などデザイン重視の印刷物では、通常は画像や表の大きさを調整して揃えますが、Webでは画像のサイズを変えたくないため、余白で調整することになります。この結果、画像が複数ある時に、画像と本文の間の余白が一定にならない、という副作用が生まれます。

二つの画像の間に、一行の本文がある場合がわかりやすいかと思います。

一定のリズムを作るデザインを心がけているのに、この余白が一定で無いのは残念です。また、大きなブロックをまたいだ場合、上に挙げたメリットは小さくなってしまいます。脳が画像をまたいでパターン認識するのは困難ですし、目線が画像の次の行頭を見つけるのは簡単です。

この点から、大きな画像や表に対しては、画像をリサイズできない場合には「バーティカルリズム」を適用せず、余白を一定にする手法が一般的に使われる、と「日本語組版処理の要件」および、JIS X 4051「日本語文書の行組版方法」では定めています。

W3Cでの議論を見ると、この点が、英語圏由来の「バーティカルリズム」と、日本語本来の「行取り」では大きく違うようで、英語圏由来の「バーティカルリズム」は、余白の調整は断念し、常に適用する場合が多いようです。対して「日本語組版処理の要件」では、行取りの処理例は、見出しの説明の中でのみ出てきます。日本語は、文字の高さが一定のため、画像と本文の余白を、英語の場合よりも気にするのかもしれません。

本記事では、適用する場合と、空白を揃える場合の両方のパターンを使って、本文と見出しにのみ適用してみます。

CSSコーディング

提案中の line-height-step プロパティを設定すると、行の高さが設定値の倍数になるように切り上げられます。これを使って、CSSを書いてみましょう。便宜上、見出しは <h2> と <h3>、本文は <p>、画像やコラムは <div> タグを使っているとします。

line-height-step プロパティはまだChromeの試験運用機能でしか使えないので、まずは @supports で囲みます。ブラウザで表示を確認する場合には、Chromeのアドレスバーに「chrome://flags」と入力し、表示された画面で「Experimental Web Platform features」を有効にしてください。

article {
  font-size: 16px;
}

@supports (line-height-step: 1px) {
  article {
    --grid: 24px;
    line-height-step: var(--grid);
  }
}

日本語の行間は、フォントサイズの1.5倍から1.8倍くらいが読みやすいとされていますので、ここでは font-size を1.5倍にした 24px を基本のリズムとします。この値は他でも使うので、CSS Custom Properties で定義して、line-height-step プロパティを設定します。

基本のリズムを設定したら、本文の設定をします。

article > p {
    line-height: 1.2;
    margin: 0;
  }
  article > p + p {
    margin: var(--grid) 0 0 0;
  }

line-height-step を使う時には、margin をリズムの整数倍に揃える必要があります。個人的には日本語の段落間の空きはない方が好みなのですが、Webでは空ける場合も多いため、ここでは段落間を一行空きに設定しています。後で出てきますが、margin collapsingが使えない場合があるため、隣接セレクターを使っています。

また、line-height-step が行間を一定に揃えてくれるため、誤って余分な空白が入らないように line-height を小さめに設定しています。通常は問題ありませんが、複数のフォントが使われた時などには、CSSの仕組み上、行間が広がってしまう場合があるためです。

次に、画像や表は適用外とします。margin は見た目を確認しながら適当に設定してください。

article > div, article > table {
    line-height-step: 0;
    margin: .2em 1em;
  }

最後に、見出しを「行取り」で揃えてみましょう。

article > h2, article > h3 {
    display: inline-block;
    width: 100%;
    line-height-step: 0;
    line-height: 1.2;
    margin: var(--grid) 0 0 0;
  }

ちょっとおまじないが出てきました。実は、line-height-step は行の高さを揃えるだけで、ブロックを揃えることができません。ブロックを揃えるための仕様も議論には上がっているのですが、行の議論でもう二年近く経っているので、ブロックの議論や実装は残念ながらまだ先です。このため、現段階でブロックを揃えるには、ブロックを inline-block にして行の中に収め、その行を揃える、という手法を取ります。width は、この inline-block を含む行を幅いっぱいにするためです。

これで <h2> や <h3> の高さは常に 24px の倍数になるように上下に余白が入ります。

モバイルなどの狭い画面では、見出しが複数行になる機会もあるので、このブロックの中では line-height-step をオフにし、小さめの line-height を設定します。見出しは、短めで、フォントも大きいので、通常は行間を詰めた方が見やすくなります。

最後に、見出しの上部の空きを、下部の空きより大きくするため、margin-top のみを一行分に設定します。これも好みですが、実際の空きは、「行取り」の調整のためにこれよりも大きくなるため、確認しつつ適切な値を探してみてください。上下の margin の合計値は 24px の倍数になるようにする必要があります。また、inline-block にしたため、隣接したブロックとの間でmargin collapsingが働きません。<p> で隣接セレクターを使ったのはこのためです。

これで完成です。試験運用機能を有効にしたChromeで確認できるはずです。サンプルはこちらにあります。確認が終わったら、試験運用機能は無効に戻しておいてください。

最後に

多くの方が、試されて最初に感じるのは「あんまり変わらないね」ということではないかと思います。ほぼすべての日本語ワープロにこの機能が入っていますが、気がついている人は多くはないのではないでしょうか。「行取り」「バーティカルリズム」のみならず、多くのタイポグラフィの改善は、一つ一つは非常に小さな変化ですが、積み重ねることで確実に読みやすくなります。ぜひ、お試しください。

前回までで、Enduring CSS（以降ECSS）の考え方を紹介してきました。ECSSというのは端的に言うと「分けて考えよ」という設計思想です。当たり前ですけれども、どう「分けて」考えるかは、設計者自身に判断が任されています。

ECSSには、Webアプリケーション向けに考えられた設計方法であると書かれていますが、筆者Takazudoとしては、より広い範囲で応用できる考えだと感じました。今回は、どのようにECSSの考え方を活かすべきかという点について考えてみます。

コンポーネント指向のフレームワーク

2017年時点において、ReactやAngularのようなコンポーネントベースでWebアプリケーションを構築できるフレームワークが台頭しています。このようなフレームワークでは、コンポーネントの中にだけCSSを適用するアプローチを取ることができます。

• Reactを使ったモジュラーCSS : CSS-in-JSとCSS Module | POSTD
• CSSモジュール ― 明るい未来へようこそ | POSTD
• Angular – Component Styles

例えばAngularでは、コンポーネントを定義するファイルの中で、以下のようにstyleUrlsにCSSファイルへのパスを指定することができます。

@Component({
  selector: 'hero-details',
  template: `
    <h2>{{hero.name}}</h2>
    <hero-team [hero]=hero></hero-team>
    <ng-content></ng-content>
  `,
  styleUrls: ['app/hero-details.component.css']
})
export class HeroDetailsComponent {
  /* . . . */
}

ここで指定されたCSSファイルの内容は、コンポーネントの内部にのみ適用されるよう、Angularが処理します。

この方法でアプリケーションを実装すれば、CSSの特徴である、書いたセレクタがグローバルに適用されてしまうという事態を避けることができるため、意図せず他の箇所にスタイルが適用されてしまうということがなくなります。

ECSSとこれらフレームワークには直接的な関わりはありませんが、このようなフレームワークが用意している、ローカルにのみCSSを効かせるという実装を利用することで、分離による保守性の向上というメリットを得ることができます。これは、ECSSの設計思想と非常に似た考えと言えます。ECSSはモジュールごとの分離を命名規則で実現し、これらフレームワークはその用意したフレームワークの機能の中で実現します。

このようなコンポーネント指向のフレームワークを用いてアプリケーションを設計する際、ECSSを理解することは、そのCSS設計のための助けとなるかもしれません。

制作チームが別れている運用体制

筆者Takazudoは、ECSSの考え方を、制作チームが別れている運用体制にて活かすことができたという話を聞きました。

私にその話を聞かせてくれた方は、一つのサイトを複数のチームで運用する際、どこまでを共通化して考えればよいのか、汎用的なモジュールをどう考えれば良いのかということについて悩んでいたようです。制作チームが別れていると、密に連携が取れるわけではないので、汎用的に作った細かいモジュールを、各チームで共有するのが難しいということでした。

その方は、そのような環境を改善するため、ECSSの考えを取り入れました。ヘッダとフッタのみを共通のモジュールとし、それ以外の箇所については、サイト上のカテゴリのまとまりごとに完全に分離してしまうことにしたそうです。具体的には、各々の管理範囲へ個別の名前空間を与え、CSSを書く際は、クラス名の頭にその名前空間の接頭辞をつけることをルールとし、そのクラスセレクタで基本的にCSSを書くことで、競合を避けました。

また、アセットも管理範囲毎に分離し、お互いが干渉しないようにしたそうです。その結果、チームごとに触るべきファイルが明確になり、お互いの衝突を減らすことに成功したとのことでした。

これは端的に言うと、モジュールの汎用化を諦めてしまったということですが、制作の体制によってはそのような解決策がベストになることもあるかと考えさせられた話でした。CSS設計の理想とはかけ離れていると感じる方もおられるかもしれませんが、このような諦めは、実際の仕事の中では有効な解決方法となることも多いのではないでしょうか。

汎用モジュールをベースとした設計

前項で挙げた事例のような、完全にチームが別れるなどしない場合でも、ECSSの「分離する」考え方は応用できるものと筆者は考えます。というより、Webサイトをモジュールベースで考えて設計していた場合、はじめは分けて考える必要がなかろうとも、運用していたら分ける必要が出てくるというケースは往々に発生するであろうから、基本的にECSSの「分ける」設計をベースにしておいたほうが、後々の保守性の向上の助けになるであろうと感じています。

筆者は以前、コーポレートサイトをワンストップで制作することの多い制作会社にて、フロントの実装を行っていました。その会社では、コンサルから設計、デザイン、コーディング、CMS組み込みまで全てやっているという制作体制を基本としていたことと、主に制作していたのがコーポレートサイトという、汎用的なUIパーツで大量のページを作る必要があるという状況があり、これを効率的にこなすため、どの制作工程においても汎用化されたモジュールでページを構成するという意識を共有することに、それなりに成功していました。

そのような制作体制の中、HTMLとCSSでテンプレートを作っていたのが筆者だったのですが、そのようにモジュール化を強く意識していた現場であったからこそ、汎用化されたモジュールが多くなりすぎてしまうという問題に頭を悩ますことが多くありました。

具体的には、トップページでしか使わないようなメインビジュアル、一部のキャンペーンページでしか使わない特殊なモジュールなど、おおよそ他のページで使わる可能性がないようなものであっても、汎用的なモジュールとして考えてCSSの設計を行ってしまっていました。

いや、むしろそのように「汎用的である」とか「そこでしか使わない局所的なものである」などという考えの元にCSSを設計していませんでした。BEMでいうBlockの集合でWebサイトを作っていましたが、ただそれだけで、とにかくなんでも使いまわせることを念頭に置いて設計を行っていました。

そのように、局所的にしか使わないモジュールを、汎用的なモジュールであると考えて設計してしまったことで、なにかCSSの容量が増えすぎてしまい問題になるというようなことは起こりませんでしたが、今考えればそれは、サイト全体で使う汎用的なモジュールらと、局所的に使うモジュールで分けて設計すべきでした。

例えば、汎用的なモジュールはsw-（SiteWide）、トップページだけで使うモジュールはtop-（Top）、キャンペーンページだけで使うモジュールはcamp-（Campaign）と名前空間を分けるなど。そのようにしておけば、前回までで紹介したように、トップページのみのリニューアルや、キャンペーンページの更新や削除にも対応しやすくなります。

そのように名前空間によりモジュールを分けるのは、一段階、モジュールのカテゴライズを設計する必要があることに注意する必要があります。ですが、基本的に汎用的なモジュールで構成されるようなWebサイトを作る場合でも、このようにECSSの考え方を適用しておくことは、将来の保守性向上へ貢献するのではなかろうかと筆者は考えます。

CSS設計のヒントはデザインカンプの外側にあり

そのように考えていると、もはやCSSの設計について考えることは、デザインカンプを眺めながらHTMLとCSSを書いているだけでは、ベストなゴールへ到達できない問題であるということに気付かされます。前項で上げたようにモジュールのカテゴライズを考えるということは、つまるところ、Webサイトを構成するモジュールをどのように考えるのかというところに辿り着き、画面の設計をどう考えるという設計に習う必要が出てきます。

また、どのようにモジュールを切るかという点について考えた時、HTMLとCSSを書いた後の工程へ目を向けることも重要かもしれません。例えばブログシステムに組み込むためのHTMLテンプレートを書く場合、そのブログシステムが、「ヘッダ」「フッタ」を、システム的にテンプレートを分離していて、それらのファイルをインクルードするような作りになっていたとしたら、HTMLとCSSでも「ヘッダ」「フッタ」を個別のモジュールとして用意することで、ブログのテンプレート組み込みとのモジュール感を一致させることができるでしょう。

プログラミングにおいて、同種の処理は共通化し、DRYを意識するのが、良い設計を行うための考え方の一つとして重要であることはよく知られているところです。OOCSSはそのような考えに習った設計思想でした。しかし、HTMLとCSSはプログラミング言語ではないことに注意しなければなりません。SassなどのCSSプリプロセッサやPostCSSの力を借りれば近いことができますが、行き過ぎた抽象化が保守のコストを高めてしまう可能性があるのでは？と、ECSSは考えさせてくれます。保守性を見越し、行き過ぎた複雑さを排除した、適切なモジュールの分離を目指すのがECSSです。

ECSSを取り入れるべきか否かは、プロジェクトの性質によって左右されるであろうと筆者は考えます。Webサイトは作って終わりではありません。サイトローンチ後も継続して変化しうるHTMLとCSSについての保守を考える場合、ECSS的な視点も考慮しつつCSSの設計を考えてみてはいかがでしょうか。

こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、ピクセルグリッドの矢倉眞隆さんです。

矢倉さんのセッション「まあまあ最近のCSSとつらくならないための書き方」に関するスライド資料は、こちらで公開されています。

インパクト大！CSSグリッドレイアウト概要

白石: では、まずは簡単に自己紹介をお願いできますか？

矢倉: 昨年（2016年）から、ピクセルグリッド という会社で働いています。役割としては、CodeGridというフロントエンド向けメディアの運営を担当しています。

CodeGridは自社のメディアなので、技術的なチャレンジなどを行いやすいんです。なので今回のHTML5 Conferenceのセッションでは、CodeGridでの経験を基に、今後のWeb制作においてCSSの書き方がどう変わっていくかをお話ししました。

白石: 具体的には、どんなチャレンジを行ったんですか？

矢倉: CSSグリッドレイアウトを使ってみたんです。

ページのレイアウトを行う方法は、古くはtableを使ったものからfloatを使った手法、最近だとFlexboxを使ったものまで、様々な手法が使われてきました。グリッドレイアウトは、そうしたレイアウトテクニックの中でも最も新しくて、CSSの書き方を一変させる可能性のある仕様だと思います。

白石: それほどインパクトのある仕様なんですね。CSSグリッドレイアウトについて、まずは概要を教えていただけますか？

矢倉: グリッドレイアウト自体は、実は結構古くから提案されている仕様なんです。2000年代前半にマイクロソフトが提案していて、ベンダープレフィックス付きの実装はInternet Explorer 10から提供されていました。

どのような仕様かというと、名前の通り、CSSでグリッドベース（格子状）のレイアウトを可能にするものです。

CSSでグリッドレイアウトを行うためのフレームワークは、これまでも数え切れないほど提案されてきました。ニーズは非常に高かったんですね。ただ、標準として提供されている機能はなかったため、いろいろと不便なシーンもありました。グリッドを実現するために不要なdiv要素を数多く書く必要があったり、機能が高くなかったり…。

Sketchなどのプロトタイピングツールで行ったデザインを、Webデザインで再現するのが難しいのも、グリッドの機能がWebに足りなかったという理由が大きいと思っています。

そうしたグリッドレイアウトの機能を標準で提供するのがCSSグリッドレイアウトなんです。

白石: なるほど。歴史もニーズもある、待ち望まれた機能ということですね。ブラウザが標準でサポートすることで、どういうメリットがあるんでしょうか？

矢倉: まず、レイアウト用の余計なdivが減ります。またこれは憶測でしかないのですが、ブラウザがグリッドレイアウトの処理を最適化できれば、floatなどのレイアウトなどと比べ、パフォーマンスの向上も期待できるかもしれません。

あと、マークアップもよりシンプルになると思いますね。要素をグリッド内に自在に配置できるので、DOMの順序にそれほど左右されずにレイアウトができるんです。

白石: それは素晴らしい。今までは、どうしてもマークアップがどうしてもUIデザインに引きずられちゃう場面もありましたものね。

矢倉: 実際には、グリッドのアイテムに指定できるのはグリッドコンテナ直下の要素に限られていたりするので、マークアップ上の制約が全くないわけではないですけどね。ただ、レイアウト用のdiv要素を記述する場面はかなり減って、より素直なマークアップがやりやすくはなったな、と思います。

白石: CSSグリッドレイアウトは、現在どれくらいのブラウザが対応しているんですか？

矢倉: メジャーブラウザはほとんど対応済みで、Firefox, Chrome, Safariの最新版は全て対応しています。Edgeは、先日のWindows 10 Fall Creators Updateで対応しました。IE/Edgeは、古いプレフィックス付きのバージョンをサポートしていますで対応しています。

特に、Safariが10.1から対応したのは大きいですね。iOSでもかなりの割合で使えるようになったので、モバイルブラウザでの対応が大きく進みました。

白石: かなり新しい技術かと思ってましたが、もう使えるブラウザはかなり多いんですね。

矢倉: はい、Can I Useの結果を見ると、世界全体で見ると75% (プレフィックス付きを除くと69%) のブラウザで利用できるようです。

ちなみにCan I Useには、Google Analyticsと連動させる機能があるんです。そうすると、サイトを利用しているブラウザの統計から、そのサイトに限定した結果を得ることができます。

私が担当しているCodeGridは開発者向けの媒体で、新しめのデバイスやOSを利用してらっしゃる方が多いので、グリッドレイアウトが利用可能なユーザーの割合が実に95%以上に上りました。これが、私がCodeGridでグリッドレイアウトを試してみようと思った理由の一つでもあります。

Can I UseでのCSSグリッドレイアウト利用可能率

白石: Can I Use、そんな機能あったんですね…！知りませんでした。

CSSグリッドレイアウトのつかいかた

白石: では、グリッドレイアウトを使ったスタイリングの方法を教えてください。

矢倉: はい。実は、基本的な使い方はかなり簡単です。

まず基本的な考え方としては、グリッドレイアウトはまずグリッドの線を引いてから、そこに要素をあてがっていくという流れになります。

例えば、ヘッダー領域とコンテンツ領域を持つ、以下のようなレイアウトを行いたいとしますよね。

で、このようにマークアップされていたとします。

<div class="layout">
  <div class="header"></div>
  <div class="content"></div>
</div>

まずグリッドレイアウトを行うには、レイアウトのコンテナとなる要素に対してdisplay: grid;を指定します。

.layout {
  display: grid;
}

次にグリッド線を引いていきましょう。まずは縦線（列）の定義です。今回は、左右に固定で50pxを確保し、残りがコンテンツの幅になるように指定します。

以下のように指定します。

.layout {
  grid-template-columns: 50px 1fr 50px;
}

これで、以下のようなグリッド線を定義したことになります。

次は横線（行）を引いていきましょう。ヘッダーに30px、フッターに150pxを確保して、残りがコンテンツの高さになるようにします。

.layout {
  grid-template-rows: 30px 1fr 150px;
}

これで、横方向のグリッド線も引くことができました。

あとは、完成したグリッドに要素を割り当てていきます。グリッド線にはそれぞれ1から始まる（末尾から数える場合は-1から始まる）番号が自動で割り振られるので、それぞれの要素の開始位置と終了位置を指定します。

/* 1行目はヘッダー */
.header {
  grid-row-start: 1;
  grid-row-end: 2;
  grid-column: 1 / -1;
}
/* 2行目の真ん中がコンテンツ */
.content {
  grid-row: 2 / 3;
  grid-column: 2 / -2;
}

これが基本的な使い方で、他にも、グリッドの範囲に名前を付けて要素を配置することもできたりします。

コンポーネント指向の時代に備えてスタイリングしよう！

白石: では、先ほどおっしゃっていた 今後のWeb制作においてCSSの書き方がどう変わっていくかというのは、具体的にはどのようなことでしょうか？

矢倉: 結論から言うと、グリッドレイアウトを使ってみた結果、コンポーネント指向なWebアプリ開発に通じるところがとても大きいと感じたんです。

白石: コンポーネント指向というと、Web ComponentsやReactでいうコンポーネントでしょうか？

矢倉: はい、そうです。順を追ってお話しますね。

まず、私は既存のWebページ（CodeGrid）を修正してグリッドレイアウトを使うように見直していました。つまり、既存のスタイル定義がたくさん存在する状態です。

そしてグリッドレイアウトを行うには、先ほどお話ししたように、グリッドを先に定義してそこに要素を当てはめていきます。

ただ、グリッドに要素をぴったり沿わせるためには、個々の要素に既に当たっているマージンが邪魔だったんですよ。

白石: なるほど。個々の要素がそれぞれバラバラにマージンを持っていたら、グリッド内の余白もチグハグになってしまいそう。

矢倉: そうなんです。

グリッド内の個々の要素がマージンを持つんじゃなくて、グリッドのセルにあたる要素がパディングを使って余白を指定するほうが柔軟だし、管理もしやすいんです。

ただ、既存のWebページ上にはマージンの指定って至るところにあって、それらを見直していくのはなかなか大変な作業になるなと気づきました。

白石: 確かに、マージンって位置合わせのために、結構カジュアルに使いますものね。

矢倉: ここから得た学びが、「グリッドレイアウトを使う際には、個々の要素にマージンを指定するのは良くない」ということでした。

でも、そこからさらに考えを進めると、グリッドレイアウトだけではなく、コンポーネント指向なWebデザイン全般にも適用できる考え方じゃないかと思えてきたんです。つまり、「個々のコンポーネントにマージンを指定するのは良くない」ということです。

白石: グリッドレイアウトにすると、DOMの順序からも解き放たれるくらい、グリッドの要素の独立性が高まる。だから結局それらが「コンポーネント」として独立したものと見なせるようになったということかもしれませんね。

矢倉: そうです。グリッドの要素それぞれをコンポーネントと見なすようになると、要素間の空白も含めて、その配置はコンポーネントのコンテナに全て任せるべきなんです。コンポーネントの責任範囲はその内側だけに絞るべきで、その「外側」であるマージンをコンポーネント自身がコントロールすべきじゃない。

白石: なるほど…つまり、コンポーネント時代のCSSではマージンの指定を禁止するというくらいやっちゃってもいいのかもしれませんね。

矢倉: はい、そこまで徹底したルールにして、CSS Lint (CSSスタイルのチェックツール)とかで禁止しちゃってもいいかな、位に思っています。

コンポーネント間の空白については、その外側の要素がパディングで指定するようにすればいい。実際にはp要素の空白など、marginを使わないとうまく指定できないものも存在しますので、「コンポーネントの外側にマージンを指定するのは禁止」くらいのルールになるかな、とは思いますけどね。

ついでに言うと、メディアクエリもコンポーネント指向には向きません。メディアクエリを使うと、「コンポーネント自身がメディアに応じてスタイルを変える」というCSSをカジュアルに書けすぎてしまうんです。それだと、コンポーネントを別の場面で再利用しようと思った時に、使いづらいものになってしまいがちです。

コンポーネント自身は、（コンテナに）流し込まれるものであるべき。自身が幅いっぱいに広がるものとしてデザインすべきだと思います。

白石: 確かに、理にかなってますね。でも、ぼく今でもマージン使いまくりだなあ…(汗)。

矢倉: 今までは「マージン禁止」なんて誰も言いませんでしたものね(笑) 。でも今後はそういうスタイリングが一般的になっていくんじゃないかな、と思います。

あと、今までCSSの文脈で話していましたが、こういう考え方は、ReactやVue.jsなどのコンポーネント指向フレームワークとも通ずるものがあると思うんです。

そうしたフレームワークを使ってコンポーネント設計を行う時のベストプラクティスとして、コンテナ・コンポーネントとプレゼンテーショナル・コンポーネントに分けるという考え方も主流になりつつありますし（※）。

※コンポーネントを二種類に分け、プレゼンテーショナル・コンポーネントは単純な表示のみを行い、それらが配置された不可視のコンテナ・コンポーネントが振る舞いを一括で管理する、という設計思想のこと。出自はこちら

白石: 確かに、そうした考え方とも非常に良くマッチしそうですね。CSSにおいても、コンポーネント間の責務を真剣に考えるときが来たということでしょうね。

本日は興味深いお話、どうもありがとうございました！

4月にはFirefox 53とChrome 58がリリースされました。そして、Windows Creators Updateが一般公開され、Edgeも新しいEdgeHTML 15が搭載されたバージョンに更新されました。

また、Firefoxのリリースサイクルが変更され、新しい機能が実装されてからリリースされるまでの実装が短縮されることになりました。

Windows Creators Updateリリース、EdgeもEdgeHTML 15に更新

4月11日にWindows Creators Updateが公開され、Microsoft Edgeも更新されました。

• What’s new in Microsoft Edge in the Windows 10 Creators Update

開いているタブをよけておく機能の追加や、タブのサムネイルを表示するなど、ブラウザとしての使い勝手にも手が入りました。

レンダリングエンジンであるEdgeHTMLもバージョンが15に更新されており、新機能が追加されています。開発ガイドが公開されています。

• Dev guide – Microsoft Edge Development

Payment Request API、CSS Custom Propertiesなどは、Edgeのブログでも過去に取り上げられていますね。

• Simpler web payments: Introducing the Payment Request API
• CSS Custom Properties in Microsoft Edge

Intersection Observerの実装はうれしいですね。これは要素とブラウザの表示領域が交差したことを検知するAPIで、画像などの遅延ロードやパララックス的な表現の実装に役立ちます。FRESH!のパフォーマンス改善手法のひとつとしても取り上げられました。

• FRESH! Web パフォーマンス改善 〜クライアントサイド編〜 | CyberAgent Developers Blog

JavaScriptでは、Async Functions（async/await）の実装がうれしいです。今回Edgeがサポートしたので、主要ブラウザの最新バージョンすべてが対応しました。

目立たない機能の実装も…あるかも

Dev Guideの下に、実装されたAPIの一覧があったので、ブログなどでは取り上げられない機能のうち、気になったものをチェックしました。

• Element.closest()、Element.matches()の実装
• text-combine-uprightプロパティ（接頭辞なし）の実装
• outline-offsetプロパティの実装
• -webkit-text-strokeプロパティとサブプロパティの実装
• translate、scale、rotateプロパティの実装

最後のtranslate、scale、rotateプロパティですが、これはCSS Transformsの変換関数だったtranslate()、scale()、rotate()をプロパティ化したものです。プロパティになったので記述の短縮になりますし、書き順で結果が変わってしまうことのあるtranslateプロパティでの指定よりも、意図した効果を実現しやすくなります。

すでにChromeで実装されており、Edgeでの実装もとてもうれしい…と書いていたのですが、手元でちょっと試したところ未知のプロパティとなってしまいました…秋の新しいバージョンに期待します。

Firefoxのリリースプロセスに変更、Auroraチャンネルが廃止

4月18日より、Firefoxのリリースサイクルが変更されました。

• Simplifying Firefox Release Channels and Improving Developer Edition’s Stability
• Dawn project or the end of Aurora

これまでのFirefoxは、「Nightly → Aurora → Beta → Release」と4つのチャンネルに分かれていました。このうち、Auroraチャンネルが廃止され、「Nightly → Beta → Release」と、1サイクル短くなります。これにより、新しく実装された機能が手元に届くまでの期間が、これまでより1サイクルぶん（6〜8週）短くなります。

Auroraチャンネルはこれまで、Developer Editionという名前のビルドとして提供されていました。Developer Editionというシステムは廃止されないようですが、中身はBetaチャンネルになります。Beta版とのリリースとの違いは、Developer Editionはこれまで通り異なるプロファイルが作られることなどにあります。

Auroraチャンネルの廃止によって、4月19日にAuroraチャンネルに移行予定だったFirefox 55は次のサイクルまでNightlyに留まります。Nightlyが2サイクル分続くので、Firefox 55で導入される機能の数がいつもより増えるかもしれませんね。

Firefox 53リリース

4月19日に、Firefox 53がリリースされました。

• Firefox — Notes (53.0) — Mozilla
• Firefox 53: Quantum Compositor, Compact Themes, CSS Masks, and More ★ Mozilla Hacks

今バージョンからWindows XPとVistaのサポートがされなくなった（Firefox 52 ESRのサポートに移行）ほか、Macでは64ビット版のみになったことでアプリケーションのファイルサイズが減少しました。UIまわりでは、パーミッション関連のUIが改善されています。

また、Firefox Developers Editionのテーマだった「Compact」テーマがリリース版にも同梱されました。

グラデーションがなくなりフラットになった。画像はLightだがDarkテーマも。

レンダリングエンジン周りでは、以下のあたらしい機能がサポートされています。

• Firefox 53 for developers – Mozilla | MDN

CSS Textの実装で日本語の扱いが向上

Firefox 52から部分的にサポートされていたのですが、CSS Text Level 3の「Segment Break Transformation Rules」が実装され、日本語や中国語の文字間などに改行がある際の処理が変更されました。

Webページを表示するとき、HTML中の改行は半角スペースに変換されて表示されます。

<p>Hello↵
World</p>

こういう風に、改行前後に空白がなくても、「HelloWorld」ではなく「Hello World」と表示されます。この処理、単語の区切りに空白を使う言語ではよいのですが、日本語などでは不自然な箇所で空白が入ってしまい煩わしいです。

CSS Text Level 3では、改行前後の文字を見て、それが日本語や中国語のものであれば、その改行を除去して扱うという仕様が加わりました。以下のエントリで細かくまとめられています。

• 区分分断の変換規則 – おいしい

この仕様の実装によって日本語内での改行が省かれるので、改行がつくる空白に依存しているコンテンツがあれば、見た目に影響がでるかと思います。

display: flow-root

displayプロパティの値にflow-rootが加わりました。floatの解除には::afterを使う、display: tableを使うなどがありましたが、ちゃんとした方法になります。

CSS Alignmnent Level 3のplace-items, place-self, place-contentがサポートされました。FlexboxやGridで使われるalign-items/align-self/align-contentとjustify-items/justify-self/justify-contentをまとめて指定するプロパティです。

caret-colorプロパティ

先月リリースされたChrome 57でサポートされた、caret-colorプロパティがFirefoxにも導入されました。3月にリリースされたChrome 57でサポートされており、そちらで簡単に取り上げています。

CSS Transitions仕様に追加されたtransitionstart, transitionrun, transitioncancelイベントがサポートされました。MozillaのBrian Birtlesさんのブログエントリで、導入の経緯も含め簡単に紹介されています。

• MozAnime in 2016 | Nothing new

その他

アルファチャンネルを持つWebMがサポートされました。Chromeチームがつくったデモで確認できます（だいぶ気味の悪いデモですが…）

ビデオ関連では、video要素などのplay()メソッドがPromiseを返すようになりました。

auxclickイベントが実装されました。主要なボタン以外のボタンがクリックされたときなどに発火するイベントです。ChromeもChrome 55から実装しています。

• auxclick is Coming to Chrome 55

Chrome 58リリース

abbrのデフォルトスタイルが変更に

略語をマークアップするabbr要素のデフォルトスタイルが変更され、CSS3のtext-decorationプロパティを使うようになりました。以下のスタイルが、ChromeのUAスタイルシートに追加されています。

abbr[title], acronym[title] {
    text-decoration: dotted underline;
}

FirefoxもFirefox 40で変更されています。

• Firefox 40 で abbr 要素のデフォルトスタイルが変更 | フロントエンドBlog | ミツエーリンクス

多くはないと思いますが、使われているサイトでは、二重線になってしまうケースがあるかもしれません。

color-gamut媒体特性のサポート

メディアクエリーのcolor-gamut媒体特性がサポートされました。

• color-gamut media query ― Media Updates in Chrome 58

color-gamutはディスプレイの色域が特定ものにマッチするかを調べる媒体特性で、Safari 10.1でサポートされています。

前回までで、Enduring CSS（以降ECSS）の基本的な設計指針や、命名規則などのルールを紹介しました。ECSSの後半は、著者Ben Frain氏の考える、設計が破綻しないためのCSSの書き方が、Tipsの集合のような形でまとめられています。

ECSSは「分けて」考えることで、サイトが破綻しないようにすることに重きを置いた考え方です。なので、あらゆるサイトにとって最適な解となるわけではなく、自身の目的に合った設計を選ぶべきであると著にはあります。100%この内容にならう必要はありませんので、参考になりそうなノウハウをピックアップし、自身のプロジェクトに活かすとよいのではないでしょうか。

とはいっても、サイト全体で共通のModuleというのはあるでしょう？

前回までの内容からすると、ECSSでは「ヘッダ」「フッタ」のようなサイト全体の共通のUIを除いては、すべて名前空間でカッチリ分け、「汎用的に使われるコラム」だったり、「ナビゲーションのリスト」みたいなものも、各々の名前空間に属する、個別のModuleとして扱うべきであると言うふうに思われるのではないでしょうか。

例えば以下は、Bootstrapで用意されているPanel（左）、List Group（右）というコンポーネントです。このような見栄えのUIが何度もサイトの中で登場するのだとしても、個別のModuleとして定義しておくべきなのでしょうか。

ECSS的には、その答えはYESです。別の機能の中で登場するのであれば、別のModuleとしたほうが良いと考えます。しかし、ECSSはそのような汎用的なModuleの存在を完全に禁止しているわけではありません。例えば、サイト全体で汎用的に使われるModuleを用意したければ、sw（SiteWide）という名前空間に属させてはどうかと書かれています。この場合であれば、sw-Panel、sw-ListGroupというModuleにするという具合です。

しかしながら、このように汎用的にどこでも使えるModuleを増やしすぎないようにしたほうが良いとECSSは警告しています。理由は簡単で、そのように汎用的なModuleを増やしていけば、それはどこでも使われる可能性があるゆえに、二度と消せないModuleとなってしまうからです。

前回挙げたトップページだけをリニューアルするような例を考えてみると、その意味が分かるのではないでしょうか。トップページに登場するModule群が、汎用的にどこでも使われているもので構成されていたとしたら、前回紹介したように、もう使わなくなったModuleを消すということがやりづらくなります。

ECSSは、そのように汎用的なModuleでサイトを構成することを否定しているわけではありません。ただ、そのようにModuleの汎用化を進めていくとECSSの目指している、分けて管理するという設計からは外れていくということです。

このように、汎用的に使用できるModuleを用意することは、Module構成の複雑化とのトレードオフであると考えることができます。かたくなに汎用的なModuleを禁止する必要は無いかと思いますが、ECSS的な設計を取り入れたいのであれば、汎用的なModuleが増えすぎないように注意する必要があるでしょう。

ビルドによるCSS結合の必要性

前回、ECSSはアセットを名前空間ごとに分けると書きましたが、そのように分けたCSSやJavaScriptのファイルを、1つずつ読み込ませるのが良いと考えているわけではありません。gulp、PostCSS、Sass等を使い、必要に応じてCSSをまとめることを推奨しています。

このあたり、どうCSSをまとめるかという設計が必要と考えても良さそうです。そこまで細かく設計する必要は無いと感じるのであれば、全NamespaceのCSSを一つにまとめてしまうのでもいいと思いますが、テンプレートごとに必要なCSSは何かを把握し、どうまとめるかという設計を挟むことで、ユーザーに不必要なCSSを読み込ませないようにすることが可能になるでしょう。

筆者Takazudoは、ECSS著者のBen Frain氏に、どのようにCSSをまとめたらいいのかと聞いてみたことがあるのですが、それは自分の必要に応じて柔軟に決めれば良いとアドバイスを貰いました。

SPAなど、全てのCSSルールが1ページの上で必要な場合は、あえてCSSファイルを分ける必要がないので全部CSSファイルを一つにまとめたり、例えばキャンペーンサイトのような、そこでしか使われないという具合にNamespaceが明確に切り分けられるのであれば、それらだけを別のCSSファイルとしてまとめたりするなど、様々なまとめ方が考えられます。

PostCSSやSassとの付き合い方

ECSSでは、開発の効率化のため、PostCSSやSassなどの、CSSを書くのを手助けするツールの使用を推奨しています。ECSS書籍内で紹介されている機能の一部を紹介します。

autoprefixer

まず、ぜひ使うべきと紹介しているのが、autoprefixerです。このautoprefixer、使ったことのある人であれば分かると思いますが、autoprefixerが自動で必要なvendor prefixを足してくれるため、vendor prefixを自分で書く必要がなくなります。vendor prefixを自分で書かないといけないような状況は、コードの複雑さを高めます。この複雑さを自動で排除できるautoprefixerは、コードの保守性を高めるのに寄与するものとECSSは考えています。

変数

ほか、PostCSSやSassで利用できる、変数、mixinの機能も利用すべきであるとECSSは考えています。変数やmixinを使ってしまうと、「分けて」管理することがしづらくなくなるのではないか？と思われるかもしれませんが、まさにその通りで、利用用途に注意して、控えめに使うべきであるとECSSでは述べられています。

例えば変数ですが、ECSSでは、サイズ、色、z-indexのために使用することをオススメしています。サイズ、色を変数化しておくのは、デザインやコードの統一性を確保するためです。

既存のコードを眺める際、widthが50pxと書かれている場合と$size-doubleと書かれている場合では、コードを読む者の捉え方は異なります。前者の場合は50px以上のなんの情報も得られませんが、後者の場合、基準のサイズが25pxであり、その長さを基準にしてデザインが行われているということが想像できます。

デザインの矛盾や意図しない値の差異を発生させないため、このようなマジックナンバーは、なるべく変数化しておき、数値の指定を行うときにはこれら変数を利用するとよかろうとECSSには書かれています。

mixinとextend

mixinは控えめに使うべきであると、ECSSは考えています。控えめというのはどういうことかというと、Moduleの抽象化をするために使うべきではないということのようです。

例えばOOCSSでは、共通部分のスタイルをベースのObjectにまとめ、そこに差分のスタイルを当てたクラスをSkinとして適用することで、似た見栄えのUI表現を実現するという旨を、連載第1回で紹介しました。このようなOOCSSの設計思想を、OOCSS自身はマルチクラスを利用して実現しますが、mixinやextendを使えばスタイルの抽象化をCSS内で済ませられるため、よりスマートにModuleの抽象化が実現できると言うことができるでしょう。

しかしECSSでは、このようなmixim、extendの利用を禁止します。理由は簡単、Moduleが複雑になるからです。このmixinやextendも、汎用的なModuleを作るのと同じ問題をはらんでいます。そのような抽象化をmixinやextendで行うと、作ったmixin、extendが様々なModuleの中で使われるわけです。そうなってしまったら、そのmixin、extendをいじった場合、どこかで意図しない崩れが発生するかもしれませんから、作ったmixin、extendの内容は2度と編集することができず、「分けて」管理するというポリシーからは外れてしまいます。

もっと言えば、そんな風に最初は抽象化できたように見えても、サイトが成長していけばより色々なバリエーションのUIが登場するため、そのような抽象化を完全に行うことはそもそも無理であろうとさえECSSは考えています。（ECSSはって言うより、著者Ben Frain氏がという感じですね）

ではどのようにmixinを使うのか。その例として、ECSSではフォントに関する指定を例に挙げています。特定のfont-family、font-size、font-weight、line-heightの組み合わせを色々なところに使いたいと考えるのであれば、それは単純に変数で表せるものではないから、mixinとしてまとめ、使いまわすといいだろうと、ECSS書籍内では紹介されています。

このような、あくまで簡単なスニペット的なmixinの使い方に限定し、究極的には10個以内のmixinに収めておくのが良いだろうとECSSは考えているようです。

複雑な書き方は避けるべし

このように、ECSSは、CSSを書くことを手助けするツールの使用を推奨しているものの、そこに多くの機能を求めません。むしろ、なにか込み入った機能を持ち込む場合、その学習コストを考慮し、プロジェクトに適しているのかを判断すべしとECSSには書かれています。複雑さは運用の負荷を高めます。その結果、CSSを編集することに対してかかるコストが上がってしまうということです。

ほかにもECSSは、複雑なCSSの書き方も避けるべきであるとアドバイスしています。その例としてFlexboxを例に挙げています。Flexboxを使えば、少ない数の要素で柔軟にレイアウトを組むことができるわけですが、もし開発メンバーがあまりFlexboxに慣れていないような状況であったなら、Flexboxを積極的に使用することで得られるメリットと、Flexboxを理解するための時間を天秤にかえて考えてみる必要があるであろうと警告しています。

CSSを書いていると、新しい技術仕様をどんどん使うのがクールなコードであるように思えることはないでしょうか。筆者Takazudoは結構、そのように考えていたところがありました。対応環境の許す限り、なるべく最新の仕様をどんどん使いたいなと、まぁ技術者だとそういう欲望はある程度あるのではなかろうかと個人的には思うわけですが、それであとから見た時に読解に時間がかかりすぎてしまうようでは本末転倒です。なにを重要とするのかを考えろということです。

これってCSSだけではなく、プログラミング全般に言えることだとも思うのですがどうでしょうか。

※ Enduring CSSが書かれた時期からするとFlexboxはだいぶ普通に使われるようになってきたかと思いますので、そこまで警戒すべきものではないかとは思いますが、重要なのは、開発メンバーがその技術に慣れているか否かという点です。

今回は、ECSS書籍内より、実装のヒントとなりそうなトピックのうちのいくつかを紹介しました。ECSSには、他にもたくさんの実装のヒントがありますので、ご興味が有る方は是非、ECSSのサイトをチェックしてみるといいかと思います。

次回は、ECSSをどのように利用していったらよいか。実際に書いてみて気をつけたほうがよさそうなことを筆者なりにまとめて、締めとしたいと思います。

そんな時代に、Web開発はどう変わるのか？まずはCSS設計というところに着目して聞いてみたいと思い、先日「Web Components時代のCSS設計」という座談会を開催し、エキスパートの方々にお話を伺ってみました。

ゲストのエキスパート紹介

高津戸 壮さん

株式会社ピクセルグリッド フロントエンドエンジニア

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。著書に『改訂版 Webデザイナーのための jQuery入門』がある。CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

小原 司さん

株式会社ピクセルグリッド UIデザイナー

デザイン事務所で広告デザインの基礎を学び、2000年に独立。2007年頃からWebデザインにも取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。現在はその媒体の特長を活かしたグラフィックデザインに励む。マンセル色相環とムーン＆スペンサー配色理論を採用した配色アプリ『HUE360』の開発を行っている。著書に『改訂版 Webデザイナーのための jQuery入門』、『ノンデザイナーズ・デザインブック[第4版]』。

榊原 昌彦さん

一般社団法人リレーションデザイン研究所 代表理事

大学院卒業後、一般社団法人リレーションデザイン研究所立ち上げ。その後、まちづくりの産業化を目指す一般社団法人エリア・イノベーション・アライアンスにも参画し、全国の様々なまちづくりの現場に携わる。事業の構造的転換を図り、Webを導入。事業で用いるWebアプリやシステムの開発を行っている。関西フロントエンドユーザーズグループを中心に活動し、CodeIgniter、Ionic2、Onsen UI 2についてもSlackやTwitterを通じて関わる。

CSS設計の遍歴を探る…3年前、どうしてましたか？

白石: 今回の座談会は「Web Components時代のCSS設計」と題し、Web Componentsが一般的に普及した未来の話を主眼として、そこに至るまでの流れも重視したいと思っています。

過去のCSS設計から現在の皆さんのベストプラクティスの話をもとに、未来に向けた話も聞いていきます。 まずは3年前くらいから振り返っていきたいのですが、当時のCSS設計はどんなふうにしていましたか？

榊原: ちょっと調べてみたのですが、3年前というとiOS7がフラットデザインを採用した年なんですよね。

白石: おお！そう聞くとずい分昔な気がしますね。

榊原: そう、そしてCSSまわりの話でいうと、Bootstrapがフラットデザインを採用しました。UIデザインの潮流が大きく変わった年でもあります。

白石: なるほど。そういう状況下で、榊原さんはどのようにデザインを行っていましたか？ UIのビジュアルデザインも、設計という意味でのCSS設計も含めてお聞かせください。

榊原:その頃は、デザイナーがPhotoshopなどで作ったデザインカンプを元に、「ピクセルパーフェクト」で書き起こしていました。 最近は、レスポンシブなWebサイトもわりと当たり前になったおかげで、ピクセルパーフェクトってあまり聞かなくなりましたよね。

白石: なるほど。高津戸さんはいかがですか？

高津戸: 実は私と小原は3年前も今も、やっている案件自体は変わらないので、やり方自体もそれほど変わっていないんです。どういうふうにCSS設計を行っているかというと、デザインを様々な単位に分割してCSSのクラスにまとめ、そうしたパーツを組み合わせたり再利用したりしながらサイトを構築していく。レゴブロックを組み立てるような要領です。

やはり話題に上がります、OOCSS

白石: それは、OOCSS (オブジェクト指向CSS)の考え方と関係しているのでしょうか？

高津戸: そうですね…。OOCSSについて話すと長くなるので、詳細は割愛します(笑)。OOCSSはヤフーのエンジニアだったニコール・サリバンが提唱した手法で、サイトを構成するパーツを、レゴのような小さい単位のモジュールの集まりで考えるというものです。その中で、オブジェクト指向プログラミングの考え方を応用して、似通ったモジュールをクラスの継承のような実装で実現するというものです。

白石: なるほど。以前から誰かに聞きたかったのですが、例えば「テキストを右寄せにする」ための「align-right」というクラス、もっというと「8pxのマージン」をつけるための「margin-8」みたいなクラスを作って組み合わせる、というのもOOCSSと言えるんでしょうか？ 正直、あまり好みではないのですが…。

高津戸: それがOOCSSかどうか、でいえば「そうだ」と言えるとは思います。ただ、OOCSSがCSSを構造的に扱おうという考え方が広く広まっていなかった時は、そういうUIパーツをモジュール化して効率的に設計しようとした点が重要なところでした。

その頃はそれを実現する手段として、複数のクラスを一つの要素に指定し、スタイルを当てるという方法を採用していたんです。なので、そういう複数クラスを利用することがOOCSSなのかと聞かれたら、否定することはできないですけれども、複数クラスの利用＝OOCSSというわけででもないですね。

榊原: Bootstrapは、OOCSSの一つのかたちだとは思います。ただ、BootstrapなどのCSSフレームワークを使いはじめたばかりの頃に思ったのは、フレームワークの流儀に合わせるためにdivを追加していくのはどうなのかな、と。 本来不要なはずのdivじゃないですか。結果、HTMLの見通しが悪くなったりするので、こういう不満を解決するのも（後で論じる）Web Componentsの役割なのかなと思います。

白石: 小原さんは、UIデザイナーの立場でいうと、3年前はどのようなかたちでデザインやワークフローを行っていましたか？ 例えばPhotoshopでカンプを作ったりするのでしょうか？

小原: いえ、ぼくはそもそもPhotoshopは使っているわけではなくて、Illustratorを使ってます。Illustratorはキャンバスを広大に使えるので、状態違いを横に置いたり、引出線でメモを入れたりしていますね。Illustratorでデザインしたあと、そこにエンジニアにお願いすることもいろいろと書き込んだりします。

高津戸: 小原のデザインは「エンジニアフレンドリー」と言いますか(笑)、指示が細かくて適切なんです。パディングの幅とかまで書いてあることもありますし、時にはCSSのコードが書かれたJSFiddleのURLが貼られていることもあります(笑)。

小原: アニメーションなどは、実際に自分で試してみないとデザインできませんから。試してみた結果を参考として伝えるわけですが、そのまま（そのコードを）使ってくれという意味ではありません。同じような結果になる、より良いコードに書き換えてもらう前提ではあります。

デザインのコンポーネント化、そして共通化

白石: 先ほど高津戸さんが言っていた「レゴブロックを組み立てるような」構築の仕方についてお聞きしたいのですが、そういう共通化や部品化、いわば「コンポーネント化」はUIデザインの段階から考えているものなのでしょうか？

小原: いえ、UIデザインの段階では考えていませんね。その段階では全体で見ることが重要だと思っているので、パーツ単体でデザインするわけではありません。

白石: なるほどー。UIデザインの段階で共通化が可能だと判明することも多々あるんじゃないかな、と思ってお聞きしたんですよね。ボタンのパディングだとかもそうでしょうし、色なども。

高津戸: ああ、色はかなり重要ですね。色をSassの変数とかにして、共通化できるんじゃないか…というのは私たちも何度も検討しています。ただ、今はそうしていないですね。

白石: プリプロセッサはSassを使ってらっしゃるんですね？LessやStylusなどもありますが。

高津戸: はい、Sass一色ですね。

榊原: Compassとかも懐かしいですよね。

高津戸: ああ、懐かしいですね。昔、ブラウザごとのベンダープレフィックスを付けていくのにCompassの関数を利用したりしていましたが、今はPostCSSにautoprefixerというプラグインがあって、それが自動的にベンダープレフィックスを付与してくれるので、めっきり使わなくなりました。CompassってRuby Sassを前提にしていましたが、今はぼくらはより高速なnode-sassを使っています。

榊原: そうですね、そもそもCompass自体もうメンテナンスされていませんしね。

白石: で、先ほどの話に戻りますが、色をSassの変数などで管理しようとしたけどまだやっていない、と。

小原: そうですね、やっていないです。様々な場面で同じ印象を与えようとすると、色って一元的なものじゃなくなるんです。例えば同じ色のボタンでも、背景が暗い場合と明るい場合では、明るさが大きく違って見えてしまう場合があります。

そういうふうに、状況に応じて色合いの微調整を行うことを考えると、Sassの変数で一元管理するというやり方はうまく管理し続けられたことがありません。

高津戸: エンジニア的な考え方でいくと色は常に同じに思えてしまうし、一元管理が望ましいとも思えるのですが、現実と照らし合わせると難しいところもあって、今はそうしていないということです。 ただ、Sassのlighten()やdarken()などの関数を使えば、ベースカラーを派生させた色合いの微調整が可能なので、それを活用して色を一元管理できるかも…とは考えています。

白石: 最近、Sass Color Generatorという便利なものがあるのを発見して、重宝してます。

高津戸: 色については、調整のための関数がCSSの標準でも提案されていますね（著者注: CSS Color Module Level4）。

白石: おお、そうなんですね。変数とかも、CSS Variablesなどの標準でサポートされつつありますし、CSS標準にも引き続き注目ですね。

では、過去の話はこれくらいにして、現在皆さんが行っているCSSデザインという話に移行しましょうか。

CSSフレームワーク使う？インブラウザデザインする？

白石: 皆さんは、現在はどのようなワークフローでUIデザインからCSS設計まで行っていますか？ 榊原さんいかがでしょう。

榊原: ぼくは手書きでワイヤー書いちゃったら、あとは直接ブラウザ上で確認してしまいますね。 そういう流れなので、CSSフレームワークは必須です。ざっとコードを組んでしまって、ブラウザ上で確認と修正を繰り返して調整していく感じです。

SketchとかAdobe XDとか、Webやアプリに特化したプロトタイピングツールも試して便利だとは思いましたが、まだ本格的に使ってはいません。

白石: なるほど。榊原さんはインブラウザデザインが主だと。ちなみにCSSフレームワークは何を使うことが多いんでしょうか？

榊原: ぼくはFoundationを使うことが多いですね。

白石: ピクセルグリッドのお二人は、3年前とほぼ変わらない、ということでしたね。

小原: そうですね。今のところSketchは使っていません。

インブラウザデザインは、最終的な成果物を確認しながらできるというのはとても良いのですが、デザインをより良くするという視点で考えると、確認と改善をするためにコードを書かないといけないので、その分時間がかかってしまうと感じています。

ある程度出来上がってからの調整を行うにはいい方法だと思いますが、UIデザインの初期段階だとやはりツールを使ったほうがデザインを素早く行えるかなと。使い分けが大事だと思います。

高津戸: ぼくらは受託のお仕事が中心だから、というのもあると思います。お客様からの要望を聞いて、UIデザインを提案して…っていうフローが重要なので、可能な限り素早くUIデザインを改善できる形に落ち着くんだと思います。

あと、お客様からのニーズに細かく対応していくとなると、CSSフレームワークとかは邪魔になってしまうことが多い。

小原: そうですね。CSSフレームワークはあるレベルまでは便利なのですが、そこを超えて「カスタマイズ」の域に達してしまうと、途端に作業が大変なものになってしまいます。

白石: それはわかる。ぼくらが作っているTechFeedというサービスでも、現在IonicというUIフレームワークを使っているのですが、「ionic-hack.scss」っていうファイルに闇のようなコードを詰め込んでいます(笑)。

榊原: 私もBootstrap使ってた時、「bootstrap-override.scss」ってファイルを作ってましたよ(笑)。

白石: フレームワークを使うか使わないか、って話、些細なことのように思われがちですが、結構大事な話ですよね。

高津戸: ぼくらも、社内だったりプロジェクト単位だったりでフレームワークのようなものを持ってはいるんです。先程申し上げたように、レゴブロックを組み合わせて作る要領で構築を行えるように、ですね。

一般的なCSSフレームワークを使うとなると、まずいらないコードが大量についてきて、そういうコードを捨てるところから始めたくなってしまいます。 不要なコードがたくさんある、というのはプロジェクト全体の見通しの点でも、コードのメンテナンスの上でもよくないですしね。

白石: なるほど、プロジェクト内で再利用できる部分などについては、きちんとフレームワーク化、もっというとコンポーネント化しているという話ですね。 では、いよいよ最後のお題として、今日の主題である「Web Components時代のCSS設計」について話しましょうか。

Web Componentsって…なに？

白石: ではまず、コンポーネント指向とWeb Componentsについて、榊原さんに簡単に説明をお願いしたいと思います。

榊原: はい、ではこちらのスライド（Webコンポーネント時代のCSSデザイン）をご覧ください。

これはHTML5 ExpertsのWebサイトなのですが、よくみると同じようなデザインパーツが使いまわされていますよね。そういったデザインパーツを共通規格化するのがコンポーネント指向です。使い回し、というとちょっと表現悪いので、「再利用性を高める」といったりしています。

例えば、そういう思想を理論化したものとしてAtomic Designがあります。

デザインのパーツを原子、分子、生体、テンプレート、ページという粒度で構成していく。 コンポーネントの再利用については、こういったアイデアが提案されて、試行錯誤されてきました。

（榊原補足：厳密には、Atomic Designは粒度毎のコミュニケーションとワークフローデザイン論ですので、「コンポーネント指向の理論」という見方は一側面となります）

しかし、実際にコンポーネントの再利用を実践するにあたっては、これまではフレームワークや、CSSのクラス名などをやりくりして乗り切っていたわけです。

こうした問題を抜本的に解決すべく、標準技術として提案されているのがWeb Componentsです。 Web Componentsは、端的にいうと自作のタグを作れる技術です。

Web Componentsは、Custom Elements、Templates、HTML Imports、Shadow DOMと言った要素技術から成り立っています。

ブラウザによっても、要素技術によっても対応状況には差がありますが、着実に実装は進んでいますし、Polyfillを使うとほとんどの環境下で利用することができます。近い将来、あらゆる環境でWeb Componentsが利用できるようになるのは間違いないでしょう。

Web Components時代のCSS設計

白石: 榊原さん、簡潔なご説明、ありがとうございました。さて、こうして近い将来Web Componentsの普及が見込めるという状況において、CSS設計などにどう影響するかをお聞きしたいのですが…そもそもWeb Componentsってどう使われるんでしょうね。

榊原: いきなり世界がすべてWeb Componentsになることはないと思うんです。例えば昔はやった「ブログパーツ」みたいなもの、以前はiframeで作られていましたが、そういうものがWeb Componentsという形で流通して使われるようになるとか、そういうところから使われ始めるんじゃないかと。

白石: 広く再利用可能なパーツが、Web Componentsによって流通しやすくなるんじゃないかということですね。

榊原: そうですね、例えばWEBCOMPONENTS.ORGというサイトでは、そういうコンポーネントが共有されていますので、これをサイト制作やアプリ開発に一部利用していくとか、そういうあたりから使われていくんじゃないかと。

白石: では、Web ComponentsはCSS設計にどう影響を与えるでしょう？

高津戸: Web Componentsになったからいきなり変わるということでもなくて、すでに変化は始まっているとは思うんですよね。

例えばBEMやSMACSSなどは、クラスの命名規則やカテゴライズによって、スタイルの再利用性や独立性を高めています。こういう手法を採用してWebアプリを構築している場合、すでにそれはコンポーネント指向的なCSS設計を始めていると言ってもいいんじゃないかな、と思います。

白石: HTML5Experts.jpに寄稿してくださったEnduring CSSなどもそうでしょうか？

高津戸: そうですね。Enduring CSSは、NamespaceやModuleという考え方を取り入れており、Namespaceごとにアセットを分離するよう設計していくのが特徴です。

そうすることで、例えばあるページが不要になった場合、Namespaceに対応するディレクトリごとバッサリと削除してしまえる。そのように分離して管理するということがECSSの目指す設計です。

白石: なるほど。ほかには、コンポーネント指向に関連して、どのようなアプローチが取られていると思いますか？

高津戸: 私自身はまだあまり触っていないのですが、やはり、Reactなどのコンポーネント指向のJSフレームワークの存在を抜きにしては語れないと考えています。

例えば、CSS in JSやCSS Modulesは、CSSのルールを全体に当てるのではなく、コンポーネント内だけに当てるのが第一であるという思想を実装に落としこんだ一つの形であると言っていいかなと。

現時点でも、こういった技術を取り入れることで、コンポーネントを意識した設計が行えるだろうとは思います。これらを例えばReactと合わせて使うことで、CSSが従来抱えていた問題を解決し、コンポーネント指向な開発と相性のいいCSS設計を進められるんじゃないかな、と期待しています。

白石: Angularなんかも、フレームワークの機能として、コンポーネントごとにCSSを分離してくれますよね。私も使っていますが、BEMみたいに命名規約に頼らずにスタイルをカプセル化できるので、クラス名が短いままでも他の部分との衝突を考えなくてすむので気楽です。

榊原: はい、Angularを普通に使うと、CSSがコンポーネントごとにカプセル化されますね。Shadow DOMと似たような分離の仕組みをフレームワークで実現していますね（筆者注: AngularはShadow DOMを直接扱うことも可能）。

白石: 榊原さんは、Ionic2 (AngularをベースとしたUIフレームワーク。解説記事はこちら)やOnsen UI2（ReactやAngularなど様々なフレームワークと合わせて使えるUIフレームワーク。解説記事はこちら）などの、コンポーネント指向のUIフレームワークも活用されてらっしゃいますよね。

榊原: はい、そうですね。Ionicなどで素早くUIを構築してしまって、あとはブラウザ上でデザインしていく…というフローで最近はデザインと開発を行っています。

白石: BootstrapやFoundationなどのCSSフレームワークをベースに素早くUIを作って、あとはブラウザ上でいじる…というのと同様の手法でアプリケーションのデザインを行っているわけですね。

となると結局また、「CSSフレームワークを使うか否か」という先ほどの話と同様に「汎用的なコンポーネントライブラリを使うか否か」という話も出てきそうです。

とはいえ、「外部のコンポーネントを全く使わない」という選択肢もないと思うんですよね。例えばピクセルグリッドさんでも、jQuery UIのDatepicker（日付選択ダイアログ）なんかは使ってたんじゃないかと思うんですが、結局そのデザインカスタマイズなどはどうしてらっしゃったんでしょう？

小原: 実はDatepickerについても、ぼくら自作していたので…(笑)。

白石: ええっ！それはすごい。

小原: もちろん、外部のUIパーツとか、全く使わないわけじゃないですよ。お客様のニーズを満たせるもの、自分たちが求めるクオリティを満たすものがあるかどうかまずは探してみて、なければ自分たちで作るって感じですね。

…

編集後記

というかんじで、イベントは盛況のうちに終了いたしました。その後の懇親会にもかなりの人数の方々が参加され、Webエンジニア同士の交流も大いに盛り上がりました。HTML5Experts.jpは、今後もこうしたイベントを開催していきますので、ご期待ください。

最後に、イベントの様子を書き起こしつつぼくが感じた、今回の結論めいたものを最後に記したいと思います。

そもそもなぜWebにコンポーネント化が求められているのかというと、その理由の一つに「再利用性」があります。そしてその再利用性は、「プロジェクトを横断した、汎用的な再利用性」と「プロジェクト内における再利用性」の2種類が考えられます。

Web Componentsが普及することのメリットの一つは、汎用的な再利用性を持つコンポーネントの流通が活発になることでしょう。

WEBCOMPONENTS.ORGに見られるコンポーネントのリポジトリはこれからも増えてくることでしょうし、コンポーネントを有料で販売するというビジネスも早晩現れることでしょう。

そうしたコンポーネントを組み合わせて素早くアプリケーションを開発する、というアプローチは、今後より一般的になると思われます。

ただし、そうした外部ライブラリやフレームワークを使用する際に厄介なのが、カスタマイズが面倒という問題です。特に、Shadow DOMはCSSを強くカプセル化しますので、カスタマイズがより困難になる印象もあるかもしれません。

しかし、Web Components (Shadow DOM)にはコンポーネント内部をスタイリングする様々な手段があります。それらを使って「汎用的で、スタイリングも容易なコンポーネント」を開発する手法は、今後ベストプラクティスが模索されていくことと思います。

一方で受託開発のように、先にデザインを綿密に擦り合わせた後に開発に入るようなワークフローの場合、外部のコンポーネントをカスタマイズするコストや、コンポーネント内部の構造を把握するためのコスト（そして多くの場合、完全に把握し切ることはないでしょう）が大きく、外部ライブラリを利用するメリットを上回ってしまうことも考えられます。

その場合は外部ライブラリやフレームワークを使用せず、できるだけプロジェクト内や社内で完結するよう、開発用のアセットを積み上げていく方が優れたアプローチでしょう。その場合でも、Web Componentsの「モジュラリティ」や「カプセル化」、「拡張性」といったメリットは非常に大きいのではないでしょうか。

そして今回の主題である「Web Components」は、まだまだこれからの技術なのは間違いありませんが、一方現場ではとっくにコンポーネント化は必要とされ、実践もされています。

それをより良くWeb標準でサポートするための技術がWeb Componentsであり、多くの人に待ち望まれている重要な技術であることが再確認できたかな、と思いました。

2月はブラウザのリリースがなかったのですが、3月にはFirefox 52, Chrome 57, Safari 10.1がリリースされました。いくつかのブラウザに共通して大きな機能追加があったので、まずはそこから紹介します。個々のリリースについては、そのあとで取り上げます。

Firefox, Chrome, SafariがCSS Gridに一斉対応

CSS Grid LayoutがFirefox 52, Chrome 57, Safari 10.1で有効になりました。長らく試験的な実装状態が続いていたのですが、タイミングをはかったかのように一斉に使えるようになりました。

• CSS Grid – Table layout is back. Be there and be square.  |  Web  |  Google Developers
• CSS Grid Layout: A New Layout Module for the Web | WebKit

CSS Grid Layoutは、かなり強力なレイアウト用の仕様です。 ちょうど、HTML5 Experts.jpのトップページがCSS Gridの説明に都合良さそうなので、ちょっと書きながら紹介しようと思います。

HTML5 Experts.jpのトップはグリッドレイアウトを意識した見た目になっている

HTML5 Experts.jpのトップページは、ロゴやサイドバーなどのブロックが、15pxの間隔をおいて配置されています。
ちょっと線を引いてみましょう。

グリッドのガイド線を引いた。線で区切られた領域に各パーツが収まっているのがよくわかる

CSS Gridも同様に、配置する基準となる線を定義し、その線と線で区切られた領域に、コンテンツを配置します。Photoshopでガイドをひいて、その中で矩形選択をするようなかんじでしょうか。

現在のトップページをCSS Gridで書くと、このようなかんじになります。

body {
  display: grid;

  /* 縦線をひく */
  grid-template-columns: 1fr 290px 430px 290px 1fr;

  /* 横線をひく */
  grid-template-rows: 210px 60px 1fr /* 以降は割愛 */;

  /* 隙間を定義すると、隙間分の線を引かなくてよいので楽 */
  grid-gap: 15px;
}

#logo {
  /* 横の配置、2番目の線（1番目の線は左端）から3番目の線まで */
  grid-column: 2 / 3;

  /* 縦の配置、1番目の線（上端）から2番目の線まで */
  grid-row: 1 / 2;
}
...

枠だけですが、以下にコードを置いてみました。

• https://jsfiddle.net/u73q559r/

CSS Gridは機能が強力なぶん、構文も複雑です。先程書いたのは一例で、ほかにも線に名前をつけたり、アスキーアートのような構文でグリッドのセルを定義できたりします。

ドキュメンテーションやチュートリアルのサイトもすでにあるので、それを参考にしてみましょう。

• Grids – Learn web development | MDN
• Grid by Example
• Jen Simmons | Labs
• Grid Garden

このうち、Grid Gardenは、CSS Gridの構文の一部をゲームで学べるサイトです。入門にちょうどよいかと思います。

また、Firefoxの開発者ツールには、CSS Gridインスペクタが搭載されました。グリッドの線や隙間を視覚的に確認できてとても便利です。

• Examine grid layouts with the CSS Grid Inspector – Firefox Developer Tools | MDN

CSS Gridを使う場合、コンポーネントの見た目とレイアウトを、コード上ではっきり分離しないと扱いづらくなるので、マークアップやCSS設計にもいろいろ影響を与えるだろうと感じています。気が向いたら、取り上げるかもしれません。

Firefox, ChromeではWebAssemblyも有効に

こちらはFirefoxとChromeのみですが、WebAssemblyが有効になりました。

WebAssemblyについては、清水さんの連載を読んでいただくことにして、説明は割愛します。

• Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解 ― JavaScriptが動く仕組み
• Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解 ― asm.jsの仕組みとコーディング例
• Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解 ― C / C++をasm.jsに変換するツールEmscripten
• Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解 ― asm.jsを高速に動作させる新しいコンパイラーターゲットWASMとは？

Mozilla Hacksでも2月にWebAssemblyの特集が組まれています。JITコンパイラやアセンブリの話から始まるなど、読み物としても面白いものになっています。

• A cartoon intro to WebAssembly
• A crash course in just-in-time (JIT) compilers
• A crash course in assembly
• Creating and working with WebAssembly modules
• What makes WebAssembly fast?
• Where is WebAssembly now and what’s next?

この特集の他にも、asm.jsと比較しWebAssemblyが速い理由や、WebAssembly Explorerというツールの紹介もされています。

• Why WebAssembly is Faster Than asm.js
• Previewing the WebAssembly Explorer

MDNにもWebAssemblyのドキュメントがまとめられており、日本語訳も有志によって進められているようです。

• WebAssembly | MDN
• WebAssembly のコンセプト

Firefox 52

3月7日に、Firefox 52がリリースされました。Captive portal（Wi-Fiサービスのログインページ）の検出が追加されたり、HTTPなページでパスワードを扱っている場合警告が出たり、Flash以外のNPAPIプラグイン（AcrobatやSilverlight、Javaなど）が無効にされたりと、セキュリティ周りの機能強化が目立ちます。

とはいえ、フロントエンド周りの機能強化も、先述したCSS GridとWebAssemblyサポートに加えて、以下のようなものがあります。

• Firefox 52 for developers

space-evenly

Flexboxのjustify-contentでspace-evenlyという新しい値がサポートされました。

space-aroundとなにが違うかというと、space-aroundでは連続したアイテム間では空白が左右のそれの倍になってしまうのですが、space-evenlyでは「even（均等）」と名のつく通り、空白の大きさが等しくなります。仕様書の画像がわかりやすいです。

space-evenlyのほうがspace-aroundよりも使われそう

CSS Color Level 4のrgb()とhsl()

CSS Color Level 4のrgb(), hsl()関数表記が実装されました。「もとからあったじゃないか」と思う方しかいないと思いますが、CSSお得意の構文変更です。

これまでのrgb()やhsl()は、それぞれの色の値をカンマで指定していました。

それが空白区切りになりました。

color: rgb(128 90 0);

また、整数値しか取れなかったのが小数も受け入れるようになりました。hsl()については、これまで数値でしか指定できなかった色相を、角度（degなど）を使って指定可能になりました。

color: rgb(111.4 128 0.0);
color: hsl(120deg 100% 30%);

そして、これまで別の関数表記だったrgba(), hsla()の機能を統合し、rgb(), hsl()からアルファを指定できるようになりました。アルファはスラッシュで区切り指定します。また、これまでは数値のみの指定でしたが、パーセンテージでも指定可能となりました。

color: rgb(128 90 0 / 50%);

構文が変わったと書きましたが、互換性という名目で古い構文も引き続き定義されるので、移行しなければならないというわけではありません。

ES2016, ES2017のサポート

JavaScriptでは、ES2016やES2017の以下の機能が実装されました。

• Exponentiation operator（**）
• Destructuring rest parameters
• Async Functions（async/await）
• Trailing commas in functions

ES2016以降の実装について、ここ数リリースでのまとめも公開されています。

• ECMAScript 2016+ in Firefox

現在はまだ提案であるAsync Iteratorなどの実装も進められているようです。楽しみですね。

新しいResponsive Design Modeになった開発者ツール

開発者ツールでは、Responsive Design Modeが強化され、モバイル環境のエミュレーションがより細かく行えるようになりました。

• New Responsive Design Mode: RDM Lands in Firefox Dev Tools
• Responsive Design Mode – Firefox Developer Tools | MDN

UIが変わったほか、回線環境のスロットリングと、デバイスピクセル比のカスタマイズ、デバイスのプリセットなどが追加されました。回線のスロットリングができるようになったので、回線速度のレンダリングへの影響を検証しやすくなりました。

Nexus 5をエミュレートすると、画面サイズやデバイスピクセル比はもちろん、UA文字列も切り替わる

ほか、Responsive Design Modeではありませんが、アニメーションパネルではイージングの視覚化も行われるようになりました。

• Visualize animations easing in DevTools

同等の機能はChrome DevToolsにもだいぶ前からあるのですが、Escを押して現れるドロワーを開き、そこからAnimationタブを開くなど、機能への動線がよくなかったりします。

Chrome 57

Chrome 57がリリースされました。

• New in Chrome 57

フロントエンド周りの機能強化は、先述したCSS GridとWebAssemblyサポート以外に以下のようなものがあります。

text-decorationのサブプロパティが実装

CSS Text Level 3のtext-decorationプロパティが実装され、下線の色やスタイルを変更可能になりました。

これまではborderを使ってなんとかするハックだったので、これはうれしいですね。

/* リンクの下線を青色の点線にする */
:any-link {
  text-decoration-line: underline;
  text-decoration-style: dotted;
  text-decoration-color: slateblue;
}
/* text-decorationがショートハンドになったため、以下のようにも書ける */
:any-link {
  text-decoration: underline dotted slateblue;
}

Firefoxがだいぶ前から（接頭辞つきですが）サポートしており、続いて何年か前にSafariが、そして今回ようやくChromeでもサポートされました。

日本語では特に影響がありませんが、text-decoration-skipプロパティも一部が実装されました。text-decoration-skip: inkと指定すると、ディセンダなどのある文字（gやjなど）に下線が重なるのを防げます。

フォントサイズが大きいととくにうれしい

caret-colorプロパティ

CSS UIで定義されているcaret-colorプロパティがサポートされました。キャレットの色を変更できます。

input {
  caret-color: orange;
}

ファンシーな機能ではありますが、入力欄の色が薄い色になったときにコントラスト比が保てないという問題への対応でもあります。

細くて見えないかも。なおキャレットの太さなどを指定するプロパティはありません

V8 5.7ではpadStart/padEndが実装、高速化も

Chromeのバージョンにあわせ、V8も5.7になりました。

• V8 Release 5.7

新機能については、文字列の詰めを行うpadStart()とpadEnd()の導入が主でしょうか。

以前、padStart()と同様のことをするleft-padというモジュールが消えてnpmが大混乱になったので、Nodeで使えると依存を減らせて嬉しいかもしれません。

padStart(), padEnd()は、Firefox 48, Safari 10で実装済みで、EdgeでもCreators UpdateのEdge（EdgeHTML 15）でサポートされます。

他に取り上げられているのは、パフォーマンスの向上です。 正規表現周りのパフォーマンス向上については、独立したエントリが1月に公開されています。

• Speeding up V8 Regular Expressions

また、V8チームはここ数バージョンほどES2015の実行速度改善に取り組んでおり、そのエントリも公開されています。

• High-performance ES2015 and beyond

V8 5.7時点でES5と比べた実行速度差は、平均で1.86倍、中央値で1.3倍にまで減少したとのことです。

まだ差があるため「やっぱりBabelか…」という話になるかもしれません。

が、コンパイル後のES5のコードの容量が増大すれば、JavaScriptのパースなどにコストがかかり、Webアプリの最初のレンダリングまでの時間に影響します。コードの容量と実行速度、どちらも与える影響を鑑みた上で選択できるといいですね。

Safari 10.1リリース

macOS 10.12.4とiOS 10.3がリリースされ、Safari 10.1もリリースとなりました。Safari 10.1で新しく入った機能が、AppleのドキュメンテーションやWebKitのブログで紹介されています。

• Safari 10.1
• New Web Features in Safari 10.1

いくつか紹介します。

Custom Elements v1

Safari 10のShadow DOM v1サポートに引き続き、Custom Elements v1もサポートされました。

• Introducing Custom Elements

HTMLのForm Validation

ついにHTMLのForm ValidationがSafariでもフルサポートされました。

• HTML Interactive Form Validation

HTML5からtype=emailといった新しいinputの型や、required属性、pattern属性など、フォームの入力内容を調査する属性が導入されました。

検証項目に違反する入力内容があると、フォーム送信前にブロックされるという仕様なのですが、Safariは長らく対応していませんでした。DOMから入力内容がvalidかをチェックはできるのですが、UI上のサポートがなかったのがうれしくありません。

Safari 10.1では、他のブラウザと並んでフォーム送信時のチェック（ブロック）を行うようになったほか、好きなタイミングでフォームの検証状態を通知できるreportValidity()メソッドも一緒にサポートしました。こちらはBlinkのみで長らくサポートされていたもので、最近になりFirefoxもサポートしたものです。

広色域の色指定

新しいデバイスにはDisplay P3という色域の広いディスプレイを導入しているAppleですが、その恩恵をWebコンテンツでも受けられるべく、sRGBを基準としているCSSの色域を拡張する提案を行い、その一部を実装しました。

• Improving Color on the Web | WebKit

実装されたのは、color()関数とメディアクエリのcolor-gamut媒体特性です。

color()は、RGB各色の度合いを色域を含め指定できる新しい関数です。

color(display-p3 0 1.0 0)

このように指定すると、P3ディスプレイでの緑100%となり、sRGBでは表現できない、より濃い緑を発色できます。

本連載では、Enduring CSS（ECSS）というCSS設計方法論を紹介しています。

• Architect CSS and scale CSS with the ECSS CSS methodology

前回は、ECSSの考え方の特徴と、Module、及びその内容について見てきました。今回は、Namespace（名前空間）とアセットの分離について解説します。

Namespace（名前空間）

ECSSの大きな特徴の一つに、Module群をNamespace（名前空間）でまとめるという点があります。前回解説したクラスの命名規則だったり、実際のWebサイト上で使われているクラス名には、名前空間を示す接頭辞がついていました。

以下に、前回登場したクラス名の一部を列挙します。括弧内の文字列が、Namespaceです。（各モジュールがどういうものかは、第一回目の終わりに紹介したECSSサイトのトップページのモジュール一覧をご覧ください）

• home-Benefits（home）: ECSSの利点をまとめているモジュール
• home-Testimonials（home）: ECSSの推薦コメントをまとめているモジュール
• st-Nav（st）: ヘッダ部にあるナビゲーションのモジュール
• st-Footer（st）: フッタのモジュール
• hero-Standard（hero）: ヒーローエリアのモジュール

上記であれば、home-Benefitsとhome-Testimonialsはhomeに、st-Navとst-Footerはstに、 hero-Standardはheroに属するという具合です。

なお、ECSSには、クラス名上でのNamespaceは、単語の頭文字らをとったりして略称にすると良かろうと書かれています。書籍の内容によれば、ここで登場しているstというのは、Structureを意味し、ヘッダやフッタなど、サイト共通の基本構造的なModuleを属させているようです。

セレクタの競合を回避するNamespace

このように、Moduleを必ずNamespaceに属させる意味としてはまず、セレクタの重複を避けるという点が大きくあります。

どのようなCSS設計方法論を用いていたとしても、ECSSでいうModuleの名前をどうするかという点に頭を悩ませることが多いのではないでしょうか。筆者は数多くのWebサイトをコーディングしてきましたが、この名前付け作業にはいつも多くの時間をかけていました。今後どこかで使われることを見越し、どういった名前にしようかなどと考えると、最適な名前はなんだろうかと悩むのです。

ECSSは、Moduleを必ずNamespaceに属させるというルールにしています。そして、前回解説したように、Moduleのクラス命名規則が

namespace-Module

であり、Module内の要素にスタイルを当てたい場合は、その要素をChildNodeとし、

namespace-Module_ChildNode

とクラス名を付け、そのクラスセレクタでスタイルを当てるルールになっています。なので、Moduleの名前をそのNamespace内で重複しないようにさえしておけば、別のModuleのセレクタと競合することがありません。

例えば、前回例に出したBenefitsというModuleは、Namespace homeに属します（home-Benefits）。homeというのは、このサイトを眺める限り、トップページで使うModuleらをまとめるために使用されているように見受けられます。とすれば、トップページの中で重複しないModule名であればそれで良いのです。

どこかでBenefitsという名前のModuleが登場したとしても、それは別のNamespaceでの話です。hoge-Benefitsなどという、別のNamespaceを示す接頭辞から始まるクラスセレクタでスタイルが当てられるでしょうから、セレクタの競合を恐れる必要はありません。

もちろん、このように深く考えないで良いという前提としては、前回解説したように、例え似たようなModuleがどこか別のところ（この場合ですとトップページ以外）で登場しても、そのためには別のセレクタを書き、別にスタイルを当てるという、CSSの重複を許す諦めがあってのことです。

Namespaceの切り方

では、具体的にどういう風にNamespaceを用意したら良いのでしょう。ECSSでは、Namespaceの切り方として、ショッピングカートを例に挙げています。ショッピングカートの仕組みを作るのであれば、scという、ShoppingCartを略したNamespaceを用意し、そこで使われるModule群をscに属させるようにするという具合です。

この例を、もうちょっと発展させて考えてみます。

• トップページ
• 商品詳細
• ショッピングカート

という3つのテンプレートで構成されるサイトがあったと仮定します。この場合、例えばこんな風にNamespaceを分けてしまうのはどうでしょう。

トップページで登場するModuleは全てtp（topPage）に、商品詳細で登場するModuleは全てpd（productDetail）に、ショッピングカートで登場するModuleは全てsc（ShoppingCart）に属させるという具合です。

しかし、大抵の場合、ヘッダやフッタはサイト全体で共通のものになっていることでしょう。ほかにも、サイドナビにある広告エリアがどのページでも共通であるような状況を想像してみてください。そんな時は、共通Moduleをまとめるcmn（common）というNamespaceを用意してみてはどうでしょう。

cmnに、ヘッダやフッタ、サイドエリアの広告エリアを属させるのです。

例えばこんなModule名で。

• cmn-Header（ヘッダ）
• cmn-Footer（フッタ）
• cmn-SideAd（サイド広告）

これは、あくまでテンプレートの種類でNamespaceを切るというひとつの例にすぎませんので、当然、必ずテンプレートごとにNamespaceを用意せよというわけではありません。Namespaceの切り方は設計者次第であり、自由です。

このようにECSSでは、Namespaceを切ることで、セレクタの重複を防ぎます。Namespaceをどう切るかという設計は必要になりますが、Moduleの名前を考えるのは、かなり気軽になるのではないでしょうか。

アセットの分離

ECSSでは、Namespaceごとに、そのNamespaceに属するModule内で使用するCSS、JS、SVG、画像等のリソースを分離してしまうのが良いと考えています。本連載では、便宜上、これらのリソースのことを「アセット」と呼ぶことにします。

普段Webサイトを作る時、例えば以下のようにCSSやJSファイルを一つにまとめて管理したり、

/src
├── css
│   └── styles.css
└── js
    └── app.js

機能やModuleごとにCSSやJSファイルを作り、アセットの種類ごとにディレクトリを作り、ファイルをまとめたりしていませんでしょうか。

/src
├── css
│   ├── ProductDetail.css
│   ├── ShoppingCart.css
│   └── TopPage.css
└── js
    ├── ProductDetail.js
    ├── ShoppingCart.js
    └── TopPage.js

ECSSでは、ファイルタイプ別ではなく、Namespace別にアセットを管理します。前例の

• トップページ – TopPage
• 商品詳細 – ProductDetail
• ショッピングカート – ShoppingCart

だと例えば、以下のような形になるかもしれません。

/src
├── ProductDetail
│  ├── ProductDetail.css
│  └── ProductDetail.js
├── ShoppingCart
│  ├── ShoppingCart.css
│  └── ShoppingCart.js
└── TopPage
    ├── TopPage.css
    └── TopPage.js

各Namespaceのディレクトリ配下は、もっと好きなように便利に管理して良いのですが、重要なのは、Namesapce毎にアセットを分けて管理するという所です。

ECSSでは、このように分けたアセットらを、必要に応じてビルドしてまとめたりして使うよう、想定しています。

アセットの分離がもたらすメリット

Namespace毎にアセット分けられていると何が嬉しいのでしょうか。先述した、Namespaceの切り方として挙げた例をベースに考えてみます。

探しやすさ

アセット分離のメリットとしてはまず、どこにアセットがあるのか探しやすいという点が挙げられます。

例えばトップページの、以下のヒーローエリアへ配置されたtp-HeroImageというModuleの、CSS／JS／画像を探したいとします。

この場合、Namespaceごとにアセットが管理されていたとすると、このModuleに関するアセットは、トップページのアセットがまとめられているディレクトリ内にあるはずです。トップページのアセットを、/topPage（tp）に置いていたとしたら、このModuleのアセットもその中にあることが分かります。また、新しく画像やJSを追加したい場合でも、このディレクトリの中に置けばよいということも分かります。

捨てやすさ

見つけやすいという点は重要ですが、何にも増して重要なのは、使わなくなったアセットを捨てられるという点です。

CSSを書いていると、一度書いてしまったルールセットは二度と消せないと感じないでしょうか。自分一人で書いていたならまだしも、複数の人間がひとつのWebサイトのCSSを編集していたら、自分が書いていないルールセットを編集したり、消したりするのには細心の注意が必要です。ECSSの「アセットの分離」というアプローチは、これを解決する一つの方法です。

例えば、トップページのデザインをリニューアルしたいと仮定します。

この場合、それまでトップページで使っていたModule群はもう不要となるでしょうから、当然、そのModule内で使用していた画像なども不要になります。

このような場合、トップページ上のModule群をNamespace tp（topPage）に属させていたとして、そのアセットを/topPageに配置していたとすれば、もう過去のトップページのアセットは不要であると判断される場合、この/topPageディレクトリごと消してしまえばよいのです。

そしてリニューアルされたバージョンのトップページで使うModule群は、Namespace tp2（topPage2）に属させることにします。そして、そのアセットを/topPage2に配置することにしましょう。

結果として、リニューアル前のトップページで使用されていたCSSや画像などは、どこにも残りません。

もし、トップページで使っているModule群が、他のページでも使えるよう、汎用的なModuleとして作られていたとしたら、このように、簡単に消すことはできないはずです。そのように汎用的に作ってしまったModuleは、永遠にWebサイトのCSSの中に残り続ける運命にあります。

また、前回解説した、「抽象化を避ける」という点についても思い出してみてください。もしOOCSSで言うレゴのように、細かな汎用的なModuleが沢山トップページで使用されていた場合、このように古いModuleを簡単に消すことができるでしょうか。きっと、使われていないModuleを一つ一つ吟味し、慎重に消すことになるでしょう。

何を重要とするかはプロジェクトにより異なるでしょうが、ECSSは、このようにNamespace毎にアセットを分離することで、運用にシンプルさをもたらし、永続的にCSSを運用していく事ができるようになると考えます。

今回は、名前空間とアセットの分離について解説しました。次回は、ここまでで紹介していないトピックのうち、いくつかを選んで紹介します。

本連載では、Enduring CSSというCSS設計方法論を紹介します。Enduring CSSは、Ben Frain氏の著書で、末永く破綻させずにサイトのCSSを設計するにはどうすればよいか。その方法論をまとめたものです。電子書籍でも販売していますが、Webサイトで全ての内容が公開されていますので、無料で全内容を確認可能です。

• Enduring CSS by Ben Frain [Leanpub PDF/iPad/Kindle]
• Architect CSS and scale CSS with the ECSS CSS methodology

CSS設計方法論（CSS methodology）と言うと、OOCSS、BEM、SMACSSの3つが著名なものと言えるのではないでしょうか。

• An Introduction To Object Oriented CSS (OOCSS) – Smashing Magazine
• BEM — Block Element Modifier
• Ja – Scalable and Modular Architecture for CSS

特にBEMは、フロントエンド界隈でクラスの命名規則のデファクトスタンダードになったとも言ってしまっていい気がします。このEnduring CSS（以降ECSS）は、これらのCSS設計方法論と比較すると、知名度は低く、事細かにドキュメントが用意されているわけではありません。

しかしながら、ECSSの内容は筆者Takazudoにとって目からウロコであり、CSS設計に対する考え方をかなり改めさせられることとなりました。ECSSは、そこまでカッチリとしたルールではありません。サイトを長生きさせるにはどうすればいいかというヒント集のようなものと思って読むとよいと思います。

そんなEnduring CSSというCSS設計方法論を、ざっくりと紹介していきます。

ECSSの特徴

多くのCSS設計方法論では、ページを構成するUIをモジュールなどと呼ばれる単位に分け、管理するところから始めます。ECSSでもその考え方は同じです。この「モジュール」は、BlockだとかObjectだとかComponentだとか、いろいろな呼ばれ方をしますが、ECSSではこれをModuleと呼びます。

ECSSは、Module及びそのModuleの中身がどう構成されるかという考え方について、BEMを参考にしています。そこにNamespace（名前空間）や、Componentという概念を付け足したのがECSSの考え方になります。

抽象化を避けるECSS

ECSSでは、抽象化を避け、なるべく「分けて」管理することで運用の負荷を下げるというアプローチを取ります。

例えばOOCSSでは、ページを構成するUIをレゴの組み合わせで構成すると例えています。複雑なUIも単純なレゴをうまく組み合わせで構成し、新しいページを作る場合でも、既存のObjectで使えそうなものがあったらその組み合わせで構成し、足りないものは新しく作るという、HTMLとCSSの再利用を推し進めた考え方です。その結果、CSSを書く量が減るため、CSSの容量を減らすことができると。

そして、一つ一つのレゴをObjectと呼び、このObjectの変化のパターンをバリエーションをSkinという概念で表現し、オブジェクト思考における継承の考えを取り込んだ、かなりCSS的にミニマムな設計を指向しています。UIパーツをObjectで抽象化して考えるという具合です。

ECSSは、OOCSSのこのアプローチとは真逆と言ってよい考え方をします。ページを構成するUIパーツをモジュール化して管理するという点については同様ですが、多くの機能で汎用的に使用するModuleの存在をあまり良しとしません。同じような見栄えのUIパーツが登場したとしても、基本的にそれは別のものであると定義します。

そう聞くと疑問に思うことでしょう。その考えでコードを書いていったら、おなじCSSを何度もコピペすることになってしまうのでは？と。

CSSの重複を許すECSS

ECSSはそのようにCSSを重複して書くことを良しとします。

そのように考える大きな目的は、複雑化の回避です。幾つものObjectが組み合わされ、Skinでそれぞれが拡張された状態のコード。これを編集するのは、時に大変な作業になりえます。何が大変かというと、他所での影響を考慮しなければならないからです。

既に書いてあるCSSのルールセットを変更した場合、他のどこかで問題が発生しないと言い切れるでしょうか。小さなサイトであればそれは可能でしょう。しかし、複数のデベロッパーがコードをいじるような環境では、それを制御するのは困難を極めます。

そのように複雑な構造を一度作ってしまったら、ゆくゆくはコードを編集することが不可能になる。そしてCSSは破綻する。CSS容量を増やしてしまったとしても、「分ける」ことにより、これを避けるメリットのほうが遥かに大きいと考えるのがECSSです。CSSの容量増加は、gzipすれば大した差にはならないとECSSは考えています。

これは筆者Takazudoのイメージですが、OOCSSが目指すのが一つの高い塔であれば、ECSSが目指しているのはビル街です。

ECSSには、自身が大きなWebアプリケーションのCSS設計のため、合理的なアプローチが必要で考えたものであると書かれています。また、どのようなサイトにも適した考え方であると言うわけではないということも書かれています。このことは予め理解しておく必要があります。

ECSSにおけるModule内の構成

まずはECSSにおいて、Module及びその内容をどのように考えているのかを紹介します。基本的な考え方はBEMと同じなので、以下、BEMと比較する形で説明します。

例えば、こんなタブUIの構造を例に考えてみます。

BEMにおいて、このUIのタブ部分をBlockであると定義すると、

タブUI全体がBEMにおいてのBlock。これはECSSではModuleと呼びます。

そして例えば、一つ一つのタブがBEMにおいてのElement。これはECSSではChildNodeと呼びます。

状態により変化するようなパーツは、BEMではModifierというフラグを付加することで表現します。これをECSSではvariantと呼びます。

このあたりは、BEMを理解しているのであれば、呼び方が変わっているぐらいの差に過ぎません。

BEMのクラス命名規則

BEMでは、このように考えた上で、各要素に命名規則に沿ったクラスを付加し、単純なクラスセレクタでルールセットを書いていきますが、これについてもECSSは同様です。

BEMにおけるクラスの命名規則は以下です。

block__element--modifier

例えばこのタブUIのコードだと、以下のようになるかもしれません。

<ul class="tab">
  <li class="tab__item"><button>One</button></li>
  <li class="tab__item tab__item--active"><button>Two</button></li>
  <li class="tab__item"><button>Three</button></li>
  <li class="tab__item"><button>Four</button></li>
</ul>

ECSSのクラス命名規則

これに対し、ECSSにおけるクラスの命名規則は以下です。

namespace-Module_ChildNode-variant

namespaceというのは名前空間を意味しますが、これは追って解説します。他はBEMの名前が置き換わったぐらいと考えておいてよいです。

<ul class="tp-Tab">
  <li class="tp-Tab_Item"><button>One</button></li>
  <li class="tp-Tab_Item tp-Tab_Item-active"><button>Two</button></li>
  <li class="tp-Tab_Item"><button>Three</button></li>
  <li class="tp-Tab_Item"><button>Four</button></li>
</ul>

ECSS著者はBEMの区切り文字が好みではないらしく、アンダースコアとハイフンで区切りを表現します。

ほか、ModuleとChildNodeはアッパーキャメルケースで記述します。これは、多くのプログラミング言語で、クラスの宣言は大文字からはじめ、そこからインスタンスを作成することになぞらえ、HTMLにおけるこのクラス属性に指定するこの文字列は、具体的なUIを表現するための雛形であるという考えのもと、アッパーキャメルケースで記述することにしたそうです。 （筆者Takazudo的にはけっこうナルホドと思いました）

Component

ECSSでは、Module内で登場するある程度の大きさを持ったUIの塊を、Componentとして定義することにしています。

例えば、ヘッダーのModule内でプルダウンメニューが登場したら、そのプルダウンをComponentとして扱うというような具合です。その場合は、上記クラス命名規則は以下ように、ModuleがComponent名に置き換わった形になります。

namespace-Component_ChildNode-variant

どのようにComponentとしてまとめるかは各々が判断して設計する部分で、明確な切り分け基準があるわけはありません。Componentは、Moduleの大きさが大きくなった場合、コードの可読性やJavaScriptとして操作するまとまりの区切りをつけるために用意されるものと考えておいて良さそうです。

Moduleの粒度

ECSSには、Moduleは以下であると書かれています。

a module is the widest, visually identifiable, individual section of functionality.

「Moduleは、視覚的に認識できる個別の機能領域のもっとも大きな区分である」とでも訳せばよいのでしょうか。この定義からは、あまり小さい単位のUIをModuleであると定義しないような印象を受けます。

具体的なModuleの例

具体的にはどうModuleを考えればよいのか。丁度ECSSのWebサイト自体がECSSで書かれているので、そのクラス名から、Moduleの粒度がどのようなものかを見てみました。

※2017年1月時点でのWebサイトのコードを参照しています

ページの中ほどにある、ECSSの利点を述べたBenefitsというModuleです。

このようなUIをHTMLとCSSで作る場合、例えばBEMであればどのようにBlockとElementを構成するでしょうか。

明確な決まりは当然ありませんが、例えば上部にある見出し部分、アイコン一つ一つ、アイコン直下にあるラベルなどを個別のBlockとして切り出し、Blockの入れ子により構成されると考えることもできます。

他でもそのBlockが使えそうだなと、そのように細かくBlock分けをしてもよさそうですが、実際のECSSのWebサイトでは、以下のようにクラス名が振られていました。

以下は、上記で青で囲んだhome-Benefits_Unitの内容です。

このクラス名から判断されることは、このBenefitsとういうModuleは、このModule内に別のModuleやComponentが含まれておらず、中にある要素はすべてChildNodeとして構成されていることです。このことから、このModule内の要素は、このModuleの外側では一切使われないことが分かります。

また、このModuleの名称がBenefitsという、具体的な機能を示すという点についてもECSSらしいと言えそうです。もしこのModuleが他でも使用されることを想定するのであれば、IconTextSetなどという、汎用性を持った名前にしたほうが、後々都合が良いのではないでしょうか。

しかし、BenefitsというModule名からは、このModuleが、ECSSのBenefitsを表すためだけに使用されることが想起されます。

トップページにあるその他のModule群

ECSSのWebサイトトップページにおいて、他のUI群は、どのようにModule分けされているのかを見てみました。以下がその図になります。

各Module中のクラスも確認してみましたが、Module内に別のModuleがあるという、入れ子状態になっているModuleはありませんでした。また、各Module名称は、かなり具体的な単語になっているのも分かるのではないでしょうか。

単に一つのページの構成を例として挙げたにすぎませんが、このように、ECSSでは、Moduleを細かく分け、Moduleの入れ子で構成するような作りを避けることで、そのModuleがそれ自身で完結するようなModule分けを基本として考えています。同じような見栄えのUIが出ても、そのModuleの担う機能が別であれば、それは別のものとして扱います。

今回は、ECSSの考え方の概要と、Moduleについて解説しました。次回は、Namespaceとアセットの分離について解説します。