そんな時代に、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であり、多くの人に待ち望まれている重要な技術であることが再確認できたかな、と思いました。

バージョン4の変更内容はGitHub上のissueで確認することができます。この中で筆者が注目している事項は

• LESSからSASSへの変更
• アイコン（グラフィックアイコン）の削除
• IE8のサポート終了とjQuery1系からjQuery2系へ
• pxからemへの変更
• グリッドシステムに、さらに大きなブレイクポイントを追加
• ボタンのカラー指定にClass属性「default」がなくなり「secondary」を指定するようになった
• Class属性「display-*」でフォントサイズを指定可能に
• ECMAScript2015(babel)の採用
• Angularのui.bootstrapはどうなる？

現段階ではバージョン4はアルファ版ではありますが、先取りして早速レビューします。

LESSからSASS

Twitter Bootstrapはバージョン3ではLESSを用いて開発を行っていましたが、SASS版Bootstrapもあり、LESS版/SASS版の両方メンテナンスが行われていました。バージョン4からはSASSを採用することになりました。

開発者にとってこれは大きな変更です。例えば、bowerを使ってTwitter Bootstrapを利用する場合、LESS版では

$ bower install bootstrap

SASS版を利用する場合は

$ bower install bootstrap-sass-official

と、LESS版を利用するかSASS版を利用するかで呼び出すパッケージが分かれ、しかもgruntタスクやgulpタスク等のコンフィグレーションを記載する際に、それぞれの異なる記載を行っていました。こうしたことが一本化されたことは、冗長的な記述をスッキリさせてくれます。

YEOMANジェネレータにgenerator-webappというWeb開発のベーシックなジェネレータがありますが、CSS版/SASS版の切り替えのために、いたるところの分岐が書かれています。

ちなみに、bowerを使ったアルファ版のインストールは、明示的にバージョンを指定する必要があります。バージョンを指定しない場合は3系がダウンロードされます。

$ bower install bootstrap#4.0.0-alpha

アイコン（グラフィックアイコン）の削除

Twitter Bootstrapと言えば、豊富な人気のあったGlyphiconsですが、バージョン4では削除されています。

現段階では極わずかにGlyphiconsが残されているだけになっていて、入力時の警告等を表示させているだけになっています。

削除されたグラフィックアイコンですが、現状ではTwitter Bootstrapの管理外で定義されているような記述もありません。もしグラフィックアイコンを利用したい場合は、別途どこかからお気に入りグラフィックアイコンを利用する必要があります。

IE8のサポート終了とjQuery1系からjQuery2系へ

Internet Explorer8とiOS6へのサポートが終了します。Twitter BootstrapがjQueryのバージョンを1系から2系への利用変更に伴いInternet Explorer8のサポートも打ち切られました。IE8を利用する必要がある場合にはバージョン3を利用します。

さようならIE8…

pxからemへの変更

フォントサイズ等の指定がpxからem(およびCSS3で導入されたrem)に変更されました。pxはピクセル単位の指定で、環境によって変化しない絶対単位です。emは文字の高さを基準にした単位で1emは1文字を表します。特にremはCSS3で新しく定義されたroot emでroot要素（html要素）のフォントサイズを継承します。

pxの場合、ブラウザのフォントサイズを変更しても文字の大きさが変わりませんが、emではフォントサイズの大きさに合わせ表示されるフォントサイズも変わります。chromeの場合は「chrome://settings/」でフォントサイズを変更した場合に違いが確認できます。

乱暴な言い方ですが、ユーザの好みのフォントサイズに対応するというのはある意味よりレスポンシブになったと言えるのではと思います。pxが良いのかemが良いのか議論としては様々だとは思いますが、Twitter Bootstrapではemを利用します。

グリッドシステムに、さらに大きなブレイクポイントを追加

Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！でも記述されているグリッドシステムですが、4つ定義されていたブレークポイントがバージョン4ではブレークポイントが5つになり「Extra large」が追加されました。

具体的に、バージョン3では

バージョン4では

ブレークポイントにより大きなExtra largeが定義されましたが、実際には小さい画面に対するブレークポイントが追加されています。

比較するとわかりますが

※ 1emを16pxとした場合

visible-*(-block)というクラス属性ですが、バージョン４では実装されていません。これは特定のサイズのときに表示させるのもで、例えば

✔ Visible on small

としたときに「smサイズ」で表示されます。.visible-*(-block)が削除され変わりに.hidden-*-up or .hidden-*-down を利用する方向です。

ボタンのカラー指定にClass属性「default」がなくなり「secondary」を指定するようになった

btn-*では、defaultがなくなりsecondaryが新たに追加されました。defaultと同様の色を指定する場合はsecondaryを指定する必要があります。btn-primaryのバックグラウンドカラーも若干明るめに定義されています。

バージョン3では

バージョン4では

現在バージョン3とバージョン4で定義されている値を比較すると次の通りです：

こうしたカラーリングですが、ラベルやアラートに関しては今のところ変更がありません、ボタンのみ変更されています。

Class属性「display-*」でフォントサイズを指定可能に

小さい部分ですが、フォントサイズを指定するクラス属性にdisplay-*が追加されました。コメントには次のような記載があります:

> 見出し要素(h1,h2,…h6)はページのコンテンツのボディで最適に動作するように設計されています。より目立つような見出しが必要な場合は、より大きいスタイルを使用することを検討してください。

具体的には

として定義されています。しかし、CSSのfont-weightの定義がh1では500であるのに対し、display-*では300ですので若干ほっそりとした表示になります。

ECMAScript2015(Babel)の採用

Twitter BootstrapのJavaScript開発にはBabelが採用されています。Babelは、TypeScriptを使ってECMAScript 2015時代のJavaScriptを先取りしよう！での記載もあるように、今年6月に公式に次のECMAScriptとして仕様が公開されたECMAScript2015(今まではECMAScript6と呼ばれていました)の文法で記載することが出来ます。参考までに、ECMAScriptはECMA Internationalが策定した仕様で、この仕様に基いて実装されたものがJavaScriptです。

ECMAScript2015の特徴をいくつか上げると次の通りです。詳しくはこちらを参照ください。

• Arrows
• Classes
• Let + Const
• Iterators + For..Of
• Generators
• Modules and Module Loaders
• Map + Set + WeakMap + WeakSet
• Proxies
• Promises

Angularのui.bootstrapはどうなる？

AngularにはBootstrap Componentsをベースにしたui.bootstrapがあります。Angularを使って日頃開発を行っている方には、ui.bootstrapの動向も気になるところではないかと思います。というのも私は、ui.bootstrapのディレクティブ実装が非常に良いと思っているので、積極的に利用しています。

ui.bootstrapの対応に関しては現在issueで話が上がっています。ui.bootstrapはAngular2の対応もありますので、Twitter Bootstrapバージョン4の対応は難しい状況のようです。

まとめ

バージョン3からレスポンシブWebデザインを前提として作られたTwitter Bootstrapですが、バージョン4では現在のモバイル環境に合わせより強力に洗練されたCSSフレームワークです。

今回のレビューはまだアルファ版のため一部機能が実装されていない部分もありますが正式リリースが楽しみです。

＜1位＞
iOS7におけるMobile Safariの主な変更点
──白石 俊平（HTML5 Experts.jp編集長）

iOS 7上のSafariがどのように変化したかについて、Maximiliano Firtman氏（@firt）のブログから、Web制作者／開発者にとって重要と思われる情報を引用。Web技術者にとっても大きな影響を持つこのアップデートについて紹介しました。

＜2位＞
Bootstrap3超速レビュー！刷新されたグリッドシステムを理解しよう！──白石 俊平（HTML5 Experts.jp編集長）

人気のCSSフレームワーク「Bootstrap」のバージョン3が正式リリースされたタイミングで、白石編集長が早速Bootstrap3をレビュー。特にグリッドシステムを掘り下げて解説し、大反響となりました。

＜3位＞
JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例──佐川夫美雄

フロント開発の現場では、Java中心の開発から、HTML、CSS、JavaScript中心の開発にかわりつつあります。具体的な事例をもとに、実装アーキテクチャや開発インフラに、どのような変化が起きているかをレポートしました。

＜4位＞
続・よくある3つのデザインから考える、マークアップの最適解
──中島 直博

マークアップシリーズの第2回。前回のよくある3つのデザインから考える、マークアップの最適解と同じく、html5jマークアップ部主催のイベント「MarkupCafe」で出題された3つのお題から最適なマークアップを探りました。

＜5位＞
ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）
──吉川 徹

人気連載「Webサイト・アプリ高速化テクニック徹底解説」第2回。JavaScriptの高速化について、ユーザーの体感速度を向上させるための方法を紹介。JavaScriptの同期・非同期の仕組みやscript要素のasync属性、defer属性を解説。

＜6位＞
モダンな言語でHTML5を開発しよう！ 俯瞰して理解するaltJSの比較 (前篇 – TypeScript, CoffeeScript, Haxe)
──池田 泰延

2010年前後から登場したJavaScriptを生成する中間言語「altJS」。スマートにコードを書くための仕組みが用意されており、開発効率を大幅に向上させることができます。この記事では、TypeScript, CoffeeScript, Haxeについて解説しました。

＜7位＞
よくある3つのデザインから考える、マークアップの最適解
──中島 直博

html5jマークアップ部が開催したた「MarkupCafe」第1回。”フッター”、”パンくずリスト”、”求人情報”のお題をもとに、Web制作におけるマークアップの捉え方、誤った使い方をしがちな要素などについてマークアップの最適解を探ったレポート。

＜8位＞
Google Hosted Library – Webを速くするためにGoogleがやっていること Make the Web Faster 03 –
──Jxck

Googleがよく使われるJavaScriptのライブラリなどを配布している「Google Hosted Library」。実はこれはみんなが使えば使うほど、得をする仕組みになっています。その仕組となるCDNやキャッシュの技術などについて解説しました。

＜9位＞
WebP – Webを速くするためにGoogleがやっていること Make the Web Faster 01 –
──Jxck

WebPは、Googleが開発した圧縮形式で、パフォーマンスを上げるために、従来の形式よりもファイルサイズを小さくすることを目的としています。そんなWebPの概要と使い方、注意点を取り上げました。

＜10位＞
伝説のおっぱいエンジニアは先端技術の無駄遣いがお好き ── あんどうやすしさん（ミクシィ）

世界的に有名な物理エンジンライブラリ「Box2D.jsの作者」という面もさることながら、「Google Waveの人」や「おっぱいエンジニア」など「おもしろい感じの人」としても有名なあんどうやすしさんに、経歴や関心などをインタビュー。

＜11位＞
DOM操作の最適化によるJavaScriptチューニング（前編）
──吉川 徹

JavaScriptのチューニングのうち、ボトルネックになりやすいDOM操作の最適化について解説。前編・後編にわたって、DOM操作が遅くなる原因と仕組み、その解決策について詳しく解説。

＜12位＞
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 –
──Jxck

GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。この記事ではその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行い、レポートしました。

＜13位＞
HTML5のSEO－マークアップで注意すべき3つのポイント
──辻 正浩

HTML5を採用したWebサイト構築をする際に、SEOはどのようなポイントを考慮すべきなのか？　HTML5でのマークアップ、リッチ表現、SEO効果のあるh要素の使い方、HTML5で追加・削除・復活された要素などについて解説。

＜14位＞
Webアニメーションを高速化するために知っておくべき10のこと（後編）──斉藤 祐也

アニメーション／トランジションをより自然にスムーズに動作させるために知っておきたいレンダリングプロセスや、計測方法、アクシデント回避方法についてのレポート後編です。

＜15位＞
HTML5でサイトを高速化─wri.peで学ぶ、イマドキのWebアプリの作りかた（後編）
──増井 雄一郎

wri.peでHTML5をどのように活用しているかの解説レポート後編。Web StorageのlocalStorage/sessionStorageを使い、Ajax通信部分と表示の高速化を行う手法を説明しています。

＜16位＞
テレビ画面はdiv要素でできている！- Hybridcastとテレビの未来 –
──仲 裕介

NHKが2013年9月2日よりサービスを開始したHybridcast（ハイブリッドキャスト）。放送とWebが融合した新しいサービスです。今回特別に入手したHybridcastのソースコードサンプルを始め、注目トピックを紹介しました。

＜17位＞
ユーザーの体感速度を高めるためのJavaScriptチューニング（後編）
──吉川 徹

後編は、「ユーザーの操作を阻害しない」方法についてJavaScriptのシングルスレッドやイベントループを交えて解説。HTML5のWeb Workersについても紹介しています。

＜18位＞
モバイルブラウザでもサクサクに動作する最適化6つのノウハウ
──城戸 総史

モバイル端末はきちんと最適化を行えば、その分比較的低スペックな端末や3G回線であっても、サクサク軽量なサービス提供が可能です。その最適化ノウハウについて6つのポイントから解説しました。

＜19位＞
DOM操作の最適化によるJavaScriptチューニング（後編）
──吉川 徹

createElement()やappendChild()などのDOM操作メソッドを使った方法では、単純にinnerHTMLによるコードを置き換えるだけでなく、さまざまなテクニックがあります。パフォーマンスを劣化させるパターンから、そのチューニング方法を紹介。

＜20位＞
初心者でも絶対わかる、WebGLプログラミング＜基礎知識編＞
──小山田 晃浩

HTML5に関連する技術のひとつで、ブラウザ上で3DCGプログラミングを実現できる「WebGL」。今回のレポートでは「WebGLでどんなことができるのか」など、WebGLプログラミングの基礎知識について紹介しました。

2013年は多くの方に「HTML5 Experts.jp」をご覧いただき、執筆陣・編集部共々感謝しています。本当にありがとうございました。来年もどうぞよろしくお願いいたします！