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

斉藤祐也の海外WEBテク定点観測＜Issue.13: 2014/04/01-2014/04/30＞

今月の定点観測はWeb Componentsベストプラクティス、誰のためのWebなのかについて、そしてソースコード・レビューをどう行うかなどを紹介します。

注目ニュースピックアップ

Web Components ベストプラクティス – WebComponents.org

原題: Web Components Best Practices

Web Componentsはまだこれからの技術であることを念頭に、この記事では現時点でのベストプラクティスを紹介しています。

1. 名前空間: 名前空間が他のWeb Componentと重複しないよう、また3文字以内に止めることが望ましい。
2. すでに存在している要素を可能な限りまねる: ブラウザ側で実装している要素と同じように実装すること。
3. エラーを出さずに失敗する: ブラウザ側で実装している要素と同じようにDOMとのインタラクションはJSのエラーを出さないように。
4. 属性の使い方: Boolean値の属性は selected=“true” ではなく、selected のように指定する。
5. イベントを使ってデータを渡す: データが大きいか、頻度が多くない限りはカスタムイベントを利用してコンポーネント間のデータのやりとりを行う。

上記に加えて、11のリスト、合計16個のベストプラクティスが現時点で上げられています。

関連リンク:

• Accessible Web Components – Part 1 – Polymer
• The Web’s Declarative, Composable Future. – Addy Osmani
• Custom Element Interoperability – Polymer

開発者のためではなく、ユーザのために – The Sea of Ideas

原題: Winning for users, not developers

iOSやAndroidなどのネイティブアプリとWebアプリは様々な観点で比較されてきています。記事の筆者であるPaul Bakaus氏はその議論の多くで大切なポイントを見失っているとしています。
例えばURLの存在がWebの優れた点としてあげられますが、URLそのものが優れているのではなく、URLはユーザにとって共有するのに、またアクセスしやすいものであるからこそ優れているのだとしています。
議論が開発者視点のものになってしまっていて、ユーザの視点を見失ってしまっているのではないかという主張。

タスクにかかるコストと得られる価値について – NCZOnline

原題: A framework for thinking about work

あるタスクにかかるコストが高すぎるという感覚値は、開発者として経験を積んでいけば、ある程度は得られるものです。しかし、単純にリクエストに対して『コストがかかりすぎる』というだけでは、『大切な機能なんだ』と言われると議論が終わってしまいます。Nicholas Zakas氏は、この記事でタスクにかかるコストと得られる価値について、どのように考えるべきかのフレームワークを紹介しています。

ソースコード・レビュー。どうやってますか? – Shane Tomlinson

原題: How Do You Do Code Review?

複数人での開発が当たり前になるにつれ、ソースコードのレビューを行うことも増えてきています。しかし、そのソースコードのレビューをどうやるのかについての情報は、決して多くありません。Shane Tomlinson氏はこの記事で彼が実際に気をつけている点について共有しています。
記事では、どのレベルの精査が必要なのかをどう決めているのか。そして、複雑なパッチに対してどう理解度を深めているのか、小さな変更で副作用を発生させないために、何をするべきか。最後に、どのようにフィードバックを返しているのか。
ソースコードをレビューする人も、レビューを受ける人も参考になる点が多いはずです。

GitHubでオープンソースに貢献する方法 – GitHub Guides

原題: Contributing to Open Source on GitHub

すでにご存じの通り、GitHubはオープンソースへ貢献する場としては最大のサイトとなっています。そのGitHubから、これからオープンソースに貢献したいと考えている人に対してのアドバイスがこちらの記事。
すでにオープンソースに貢献している方であれば、当たり前のことばかりかもしれません。しかし、反対に自らオープンソースとしてるプロジェクトを持っているのであれば、ここで紹介している事柄を揃えておくとオープンソースへの貢献者が増えるとも言えるはずですので、ぜひ。

海外トレンドコラム

Intercomではどうやってデザインをしているか? – Inside Intercom

原題: How we design at Intercom

デザインに関する非常に有用な記事を多く提供しているIntercomのPaul Adams氏による、Intercomではどうデザインをとらえ、そしてデザインしているかの記事。実際のメールとは異なる部分もあるでしょうが、この記事ではPaul Adams氏がIntercomのメンバーに送ったデザインについてのメールを掲載してます。

関連リンク:

• And They All Look Just the Same – Cognition

モバイル・デバイスにおけるリモートデバッグガイド – Telerik Developer Network

原題: A Concise Guide to Remote Debugging on iOS, Android, and Windows Phone

モバイル開発における頭痛のタネの一つであるデバッグ。この記事は実際のモバイル端末でデバッグを行うための手法である、リモート・デバッグに対するガイドをわかりやすく紹介しています。

Web Notifications API 事始め

原題: An Introduction to the Web Notifications API

ネイティブアプリだけではなく、Webアプリでもユーザに対してプッシュ型のお知らせ、いわゆるノーティフィケーションという手法はごく当たり前になっています。この手法に対する実装はサービスごとにさまざまですが、W3CはWeb Notificationsという仕様を発表し、標準化に向けての一歩を進めました。この記事ではその仕様を利用したノーティフィケーションについて紹介しています。

アニメーションを使って支払いに関するユーザー体験を改善する方法 – Michaël Villar

原題: Improve the payment experience with animations

Stripeというサービスで、どのように支払いに関するユーザ体験を改善したのか。5つのアニメーション手法を、実際のアニメーションを見ながら紹介。アニメーションは「間」のデザインであり、支払いのようなフォーム要素で大きな影響を持つ手法ですので、参考にどうぞ。

関連リンク:

• Understanding CSS Timing Functions – Smashing Magazine

Sassを使ったユニットテスト – mts.io

原題: Sass Unit Testing

フロントエンド開発において、JavaScriptのテストは当たり前と言えるほど一般化してきました。しかし、同じくらい複雑なはずのCSSプリプロセッサのテストはどうでしょうか?
この記事では、Sassにおいてのロジック部分についてのテストをどう行うかについて紹介しています。

よりよいコード書くために知っておきたいコツ – Treehouse Blog

原題: Tips for Writing Better Code

より優れたコードを書くために、知っておきたいコツを5つ紹介。中級者くらいの経験者にとってはごく当たり前の5つですが、考えずにやっている事柄こそ、言語化するのは難しいものですので、初級者だけではなく、中級者、あるいは上級者の方にも読んでおいてほしい記事です。

パフォーマンス最適化 #perfmatters

300msのクリック遅延を抑制するための調査 – QuirksBlog

原題: Suppressing the 300ms click delay

タッチデバイスにおける300msのクリック遅延問題には多くの問題が潜んでいます。Chromeは最近この300msをmetaタグに「width=device-width」と設定することで無くし始めています。この記事でPeter Paul Koch氏は例によって事細かに「width=device-width」と300msの抑制について、実際のデバイスを使ってテストした結果を共有しています。

V8に関する資料まとめ

原題: V8 Resources

V8エンジンは言わずもがな、ChromeでもNode.jsにも利用されている非常に優れたJavaScriptエンジンです。V8エンジンのもう1つの特徴はこの種類のツールとしては多くの情報が公開されている点です。
このページではそれら情報を1箇所にまとめて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

スライド/ビデオ

HTTP2.0について

原題: http2 explained

HTTP2.0をプロダクションで利用しているというサービスはまだないかも知れませんが、今後はそれも変わっていくことでしょう。このページでは、そのHTTP2.0をプロトコルレベルから説明しているPDFそしてスライドを紹介しています。

CSS Grid Layout – Alex Danilo

Flexboxの利用が増えてきた、というタイミングですが、このスライドはCSSでグリッド・レイアウトを実装するための仕様である、CSS Grid Layoutについて紹介しています。
なかなか複雑な仕様なので、ビジュアルで解説してくれているこのスライドは非常にわかりやすくオススメです。

静的型付けは過大評価されている!? – Eric Elliott

原題: Static Types are Overrated: Dynamic Duo – Loose Types and Object Extension

ニューヨークで開催されたVelocityにて、Eric Elliot氏による『静的型付けは過大評価されている!?』と題した発表。
型の正しさだけでは、プログラムの正しさを補償するものではないとしています。彼はこの発表で、JavaScriptが持つ動的型付けの性質がアプリケーションを開発する上で、大きな武器になる点について触れています。

ツール

Internet Explorer Web Platform Status and Roadmap – status.modern.IE

Internet ExplorerにおけるHTML5、CSS3などの仕様の実装状況とロードマップを一覧できるサイト。
ちなみに、Chromeにも同様のサイトがあるので併せてどうぞ: Chromium Dashboard

SIZER SOZE

レスポンシブ・デザインにおいて、頭を悩ます問題の一つである画像の取り扱い。この扱いをおざなりにしてしまうと、単にパフォーマンスのよくないページが生まれてしまいます。このツールは、サイトのURLから画像をどれくらい無駄遣いしているのかをチェックしてくれます。

関連リンク: Picturefill 2.0: Use the picture element today – Filament Group, Inc., / Picture要素のPolyfillが最新の仕様に併せてリニューアルしていますので、上のツールの結果が気になるものであれば、導入を検討してみては?

CSS Vocabulary

CSSの用語をインタラクティブに実際のソースと照らし合わせて教えてくれるツールです。チームでの開発における共通認識は非常に大切ですから、しっかり覚えておきましょう。

Animated Bézier Curves – Jason Davies

ベジェ曲線について。アニメーションを使ってベジェ曲線がどのように描かれるかについて解説。アニメーションはD3.jsを利用して作成されているそう。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年6月2日にお届け予定です。★