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

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

今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの泉水翔吾さんです。

▲株式会社サイバーエージェント 泉水翔吾さん

泉水さんのセッションは「The State of Web Components」（ルームA 16:20-17:00）です。 （現在HTML5 Conferenceは定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

Web Componentsについてまずは復習

白石: まずは、Web Componentsについて詳しくご存じない方のために、「Web Componentsとは何か」を簡単にお話していただけますでしょうか？

泉水: Web Componentsは、一言で言えばHTML/CSS/JavaScriptといったWeb技術上で、再利用できる部品作りを促進する仕組みです。

ReactやAngularなど、昨今のフレームワークを使えば、WebのUIをコンポーネントとして扱うのはすでに可能です。しかし、例えばCSSが単一のグローバルスコープしか持たなかったり、インポートする仕組みが弱かったりするという問題は、ブラウザがネイティブに対応することが望まれる問題なのです。

白石: 具体的な技術として見た場合、Web Componentsとはどのような技術なのでしょうか？

泉水: 大きく分けて4つの仕様からなっています。

1つ目はShadow DOM（仕様）。個人的には一番のポイントとなる技術だと思っています。

コンポーネントはそれぞれ、メインのDOMツリーから分離された、独自のDOMツリーを持つことができるようになり、それをShadow DOMといいます。Shadow DOMはそれぞれ異なるスコープを持つため、CSSやJavaScriptの名前空間が他と干渉しません。

例えば、一度作ったUI部品を、一年後にまた別の箇所で使おうと思った時、CSSのクラス名がかぶってしまってうまく扱えない…などの問題はありがちです。そういう問題を根本的に解決する手段として、Shadow DOMはとても有望な技術です。

2つ目はCustom Elementsです（仕様）。

これは一言で言うと「独自の要素を作れる」技術です。 customElements.define()というAPIを用いて自由に要素を作成でき、作った要素は通常のHTML要素と同じくマークアップが可能です。Web Componentsによる「部品の再定義」とは、この「独自の要素を作って、使える」というCustom Elementsの機能を指すことが多いと思います。

3つ目はtemplate要素です（仕様）。

テンプレートとして使いたいHTMLを定義するための要素で、すでにほとんどのブラウザが対応しています。昔は、そういうテンプレートは不可視のdiv要素だとか、独自のtypeを指定したscript要素の中に書くのが通例でした。

標準の要素を用いてテンプレートを扱えるようになったことで、セマンティクス上わかりやすくなったり、テンプレートをDOMとして扱えるのでセキュリティ上の懸念があるinnerHTMLを利用する必要がなかったり、テンプレート内にimg要素があったときに画像のリクエストが行われてしまう…といった問題を避けられるようになりました。

最後はHTML Importsと呼ばれている仕様でした（仕様）。この仕様はもともと、link要素を用いて他のHTMLファイルを読み込むことができるというものです。

ただ、この仕様には反対するブラウザベンダーも多く、実装は進みませんでした。代わりにES Modules（※）の実装が進んできたので、まずはそれを使ってコンポーネントを宣言するJavaScriptを読み込む…というのが、当面はスタンダードな手段になりそうです。

※ES Modules…ECMAScriptで定められた、モジュールを扱うための標準仕様。import {XXX} as 'module';のような形式で、他のモジュールを読み込むことができる。

Web Componentsが「ようやく使える」わけ

白石: 泉水さんがHTML5 Conferenceのセッション説明に書かれていたことによると、Web Componentsは「ようやくまともに使えるようになりそう」とのことですね。これまでなぜまともに使えなかったのか、そしてどのように状況が変わってきたのでしょうか？

泉水: ブラウザの対応が進まなかったというのが、これまでまともに使えなかったという理由です。

Web Componentsはもともと、2011年にGoogleが提案したものでしたが、ブラウザの反対にあったり実装されなかったり…という部分がとても多かった。 Shadow DOMやCustom Elementsの当初の仕様は「v0」（バージョン0）と呼ばれていて、ほぼ「なかったこと」になっています。

しかし、仕切り直された「v1」でようやくブラウザベンダーの合意形成がなされて、実装も進んできた。特にSafariの実装が進んできたのが大きいですね。やはり、iOSの存在感はとても大きいので、Safariで動かないとなると、「使えない」「使いにくい」と見なされるのが普通ですから。

先程申し上げた仕様で言うと、Shadow DOMはChromeとSafariでほぼ使える。 Custom Elementsも同様に、ChromeとSafariが対応しています。 template要素はIEを除くほぼすべてのブラウザで使えますし、ES ModulesもChrome、Safariが最新版で対応済みです。

白石: こうして見ると、むしろモバイルブラウザのほうがWeb Componentsを使いやすそうですね。最新版のブラウザであれば、ほぼ100%対応している。ようやく、時代がWeb Componentsに追いついてきたという感じですね。

Web Componentsの「作りかた」

白石: では、Web Componentsに準拠したコンポーネントはどのようにして作るのでしょうか？フレームワークやライブラリを使ったほうがいいですか？

泉水: 現時点だと、全てのブラウザがWeb Componentsに対応しているわけではないので、Polyfillの利用は考えたほうがいいかもしれませんね。 webcomponents.jsというライブラリがあるので、それを読み込んでおけば、あらゆるブラウザでWeb Componentsのコードが動作するようになります。

その上でまずは、素のJavaScriptで全然作っていけると思います。私の作ってみたサンプルがGitHubに上がっているので、そちらを例に取って説明しますね。

まずコンポーネントの作り方ですが、既存のHTML要素を継承したクラスを作ります。

// fancy-button.js
// ↓のコードを記事用に改変
// https://github.com/1000ch/webcomponents-sandbox/blob/master/fancy-button.js
export default class FancyButton extends HTMLElement {
  static get template() {
    return `
      <style>
        button {
          display: inline-block;
          /* 中略 */
        }
      </style>
      <button>
        <slot></slot>
      </button>
    `;
  }

  constructor() {
    super();
  }

  connectedCallback() {
    this.attachShadow({
      mode: 'open'
    }).innerHTML = FancyButton.template;
  }
};

コンポーネントを使う側は、そのコンポーネントをimportで読みこんで、customElements.define()を使ってカスタム要素を生成します。後は普通のHTML要素と同様に使っていけばいい。この例では、<fancy-button>というタグが使えるようになりました。

// app.js
// ↓のコードを記事用に改変
// https://github.com/1000ch/webcomponents-sandbox/blob/master/app.js
import FancyButton from './fancy-button.js';

customElements.define('fancy-button', FancyButton);

白石: この例でいくと、styleやその他の要素を文字列として定義しておくんですね。

泉水: そうですね。将来的にもこうした方法がスタンダードになるかはわかりませんが、現時点ではPolymer 3.0なども同様の方法を取っています。

Web Componentsに関連するライブラリやサービス

白石: Polymerとはなんですか？

泉水: Web Componentsの開発を促進するライブラリです。データバインディングなど、コンポーネントを作るのに便利な機能が数多く含まれています。現在は3.0が開発中で、コンポーネントのロード手段がHTML ImportsからES Modulesに変更されたり、APIが大幅に変わったりする予定です。

白石: その他、Web Componentsに関連するライブラリとか、サービスってありますか？

泉水: webcomponents.orgはWebComponentsのポータルサイトで、Web Componentsに関する情報や、公開されているコンポーネントが載っています。Polymerプロジェクトが作ったコンポーネントも多数公開されていて、‘iron’という接頭辞が付いたものはコアコンポーネント、‘paper’という接頭辞が付いたものはマテリアルデザインのコンポーネントです。

白石: Polymer以外にも、Web Componentsのライブラリってあるんでしょうか？

泉水: webcomponents.orgに一覧があります。例えば、SkateJSは軽量なライブラリで、Reactライクな仮想DOMを持ち、stateやpropsの管理も行ってくれるというものです。

YouTubeはWeb Componentsを使っている！

白石: Web Componentsがようやく使える段階に来ているということで、何か事例とかあったりするんでしょうか？

泉水: 事例で言うと、YouTubeがWeb Componentsを使っているというのは有名ですね。去年発表されて話題になりました。最近デザインもリニューアルされましたが、Polymerを使っているようです。

白石: YouTubeが！凄まじい利用者数もいるだろうに、そんなドラスティックな改変を行っているだなんて…。

泉水: YouTubeのチームは、すごく攻めるらしいんです(笑) 。ただYouTubeチームは、素のWeb Componentsを使っているわけではありません。

YouTubeのHTMLソースを見てみると、確かにたくさんのカスタム要素を使っているのですが、Shadow DOMは使っていないんです。

白石: 本当だ、yt-って接頭辞の付いたタグをたくさん使ってるけど、それらの中身は通常のDOMですね。

泉水: 聞くところによると、Shady DOMやShady CSSというWeb ComponentsのPolyfillを使っているそうです。Shady DOMやShady CSSは、Web Componentsの動作を完全にエミュレーションするわけではないのですが、そのかわりに動作が軽量です。

白石: なるほど、それでWeb Componentsと互換性のあるコードを書いているというわけですね、きっと。

Web Componentsの気になることを何でも聞いてみる

白石: では、あとはWeb Componentsについて聞きたいことをいくつか用意してきたので、順に質問させてもらってもいいですか？

泉水: はい、お答えできることであれば何でも答えます。

白石: 例えばアクセシビリティはいかがでしょうか。Web Componentsが広まると、たくさんの独自要素が開発者の手によって作られていくことになると思いますが、それでもアクセシビリティは担保できるものなのでしょうか。

泉水: それは問題にならないと予想しています。

Web Componentsの中身は、結局のところ一般的なHTML要素から構成されますので、そうした要素が持つセマンティクスなどをブラウザが活用することは可能です。また、アクセシビリティ情報を付与したければ、自作のコンポーネントにWAI-ARIAの属性などを指定していくこともできるでしょう。

白石: ReactやAngularなど、既存のフレームワークとWeb Componentsの関係はどうなりますか？うまく組み合わせて使っていけるものなのでしょうか？

泉水: 私もあらゆるフレームワークを知っているわけではありませんが、Reactに限って言うなら、組み合わせて使うことは難しくありません（筆者注: Reactのドキュメントにも言及がある）。

Reactのコンポーネントを、Shadow DOMにするのも難しくはないと思います。仮想DOMから実際のDOMをレンダリングする部分で、通常のDOMの代わりにShadow DOMを使えばいい。

白石: そうすることによる利点には何があるでしょうか？

泉水: やはり、CSSがコンポーネントごとに分離できるのはうれしいですね。私はCSS Modulesとかがあまり好きではないので、標準的な仕組みでそれが行えるのであればすごく嬉しいです。

白石: CSSの分離という話でいうと、コンポーネントを使う側が、コンポーネント内のスタイルをカスタマイズしたいという要望は必ずあるかと思います。ですが、コンポーネントは基本的にスコープが閉じているので、外からスタイルを当てるのは工夫が必要ですよね。それについてはどう対応するのが正解なのでしょうか？

泉水: CSSカスタムプロパティを使うことですね。コンポーネント側では、使う変数名を決めておき、var(--変数名, デフォルト値)と指定して使用します。こうすれば、コンポーネントのデフォルト値でレンダリングはされつつも、呼び出し元で変数を指定すれば、コンポーネントのスタイルを上書きすることができます。
（筆者注: Google Developersの文書に詳しく説明がある。Shadow DOM v1: 自己完結型ウェブ コンポーネント）

白石: ほか、最近Web Components周りで気になっている話題とかはありますか？

泉水: そうですね、コンポーネントの読み込みに関する部分はかなり気になるところです。

例えば、先程もコンポーネントをES Modulesで読み込むのが一般的になりそうだというお話をしましたが、一つ問題がありまして。type='module'を指定したscript要素（筆者注: JavaScriptモジュール）って、デフォルトでdeferで読み込まれる（※）ので、コンポーネントを宣言するJavaScriptの実行がどうしても遅くなってしまうんです。

なのでそうなると、コンポーネントを宣言するJavaScriptがロードされるまで、カスタム要素の中身がそのままレンダリングされちゃうっていう事態が発生してしまうんですよね。

※script要素がdeferで読み込まれる…defer属性を指定されたscript要素は、レンダリングをブロックしないようにレンダリング処理と並列で読み込まれ、DOMContentLoaded終了後に実行される。

白石: おお、それは、先日ソフトバンク・テクノロジーの関口さんに伺ったWebフォントの話（「フォント素人のWebエンジニアが、「フォントおじさん」に聞いてみた！Webフォントの最近の事情とか」）にも近いものがあるかもしれません。Webフォントの場合も、フォントファイルの読み込みが終わる前にシステムフォントでレンダリングされてしまうという問題があって、それをFONTPLUSでは独自に、該当要素を非表示にすることでちらつきを抑えているそうです。

泉水: 同様の対処が必要かもしれませんね。

あともう一つ、コンポーネントの読み込み周りで気になるところでいうと、HTML ImportsならぬHTML Modulesっていう仕様が最近議論されていましたね。これは、importにHTMLファイルを指定できるようにしようとするものです。

白石: それはなかなかアグレッシブなアイデアですね。ES Modulesで、コンポーネントのJavaScriptを読み込めるようにするというだけでは、やはりまだ満たせないものがあるということでしょうか。

泉水: やはり、ES Modulesだけだと、どうしてもJavaScriptが中心になってしまうんですよね。先程お見せしたコードでも、HTMLやCSSのコードを文字列としてコンポーネントが保持していました。でも、あれはそれほどいい方法とも思いません。マークアップやスタイリングを分業しやすいよう、JavaScriptファーストではない方法についても、検討の余地はまだまだあるということだと思います。

白石: なるほど、Web Compornentsの周りでも、まだまだ面白い展開が待ってそうですね。本日はいろんなことにお答えいただき、誠にありがとうございました！

Web Componentsが変えるWeb開発の未来から、はや二年が経ちました。コミュニティでの議論やフィードバックを経て2016年現在、Web Componentsの仕様は大きくアップデートされています。先日行われたDevFest Tokyo 2016でもWeb Components 2016 & Polymer v2 と題してWeb Componentsの最近についてお話しました。

これまでGoogleを中心に策定されてきたv0の仕様を元に、新しい仕様はMozillaやAppleなどの各ブラウザベンダーの合意を改めてとりながら策定が進められています。今日はアップデートされたWeb Componentsの仕様を説明していきます。

基本概念については割愛しますが、えーじさんのShadow DOM – Web Componentsを構成する技術:Tender SurrenderとCustom Elements – Web Componentsを構成する技術: Tender Surrenderがわかりやすいので、Shadow DOMやCustom Elementsが何なのかわからない人はまずこちらを見ましょう。

Shadow DOM v1の仕様

Shadow DOMはDOMにスコープをもたらす重要な仕様です。v1においては、基本的なコンセプトはそのままにAPIが見直されています。

createShadowRoot()からattachShadow()へ

createShadowRoot() で行っていたShadow Rootの作成ですが、v1では attachShadow() を使います。関数がShadow Rootを返す点はこれまで同様です。

const div = document.querySelector('div');
const shadowRoot = div.attachShadow({
  mode: 'open' // or 'close'
});

// readonly な shadowRoot プロパティの追加
console.log(div.shadowRoot);

attachShadow() は引数にオプションを取ります。v1においてShadow DOMにはOpenedなモードとClosedなモードが存在し、mode: 'open' または mode: 'close' のように指定します。

Shadow DOMをホストできるHTML要素に shadowRoot という読み取り専用のプロパティが追加されており、要素のShadow DOMはこれを通して参照します。要素が Shadow DOMをホストした時点で shadowRoot プロパティは参照を返すようになり、Shadow DOMがないうちは null です。DevToolsで document.querySelector('div').shadowRootを実行すると undefined ではなく null が（きっと）返ってきます。

OpenedなShadow DOMとClosedなShadow DOM

Shadow DOMのモードにOpenedとClosedがあることを先に述べましたが、これはShadow DOMの外の世界からアクセスできるかどうかを示します。このため、外部からアクセス不能なClosedなShadow DOMをホストする要素の shadowRoot プロパティは、null を返します。

外部からのアクセスを許すべきか封じるべきかは賛否両論があったため、このモードという形で合意形成されました。

ClosedなShadow DOMをホストする要素は第三者に編集されないので、コンポーネントを作ったときに独立性を保つことができます。ネイティブの video 要素を Chrome で閲覧すると、各種制御UIがShadow DOMで実装されていることがわかりますが、このように外部から操作されたくない場合にはClosedモードが適しているのでしょう。逆にOpenedでアクセスの余地を残せば、より柔軟にコンポーネントを利用できるはずです。

複数Shadow Rootの廃止

v0では単一の要素に対してShadow Rootを複数持つことが許可されていましたが、v1では禁止されます。そのため attachShadow() を2回以上実行すると例外が発生します。

Shadow DOMをホストできる要素が限定的に

v0ではあらゆる要素がShadow DOMをホストすることが可能でしたが、v1では限定的になります。許可が予定されているのは次の要素です。

article, aside, blockquote, body, div, footer, h1, h2, h3, h4, h5, h6, header, 
nav, p, section, span

これらのネイティブ要素に加えて、カスタム要素もShadow DOMをホストできます。inputや imgなどの置換要素がShadow DOMをホストできなくなるようです。

Insertion PointsからSlotsへ

カスタム要素で囲むコンテンツがどのように表示されるかは、カスタム要素に含まれる content 要素によって挿入先（Insertion Points）が決まっていました。v1では slot 要素によるSlotsに変わります。

form-container というカスタム要素を例に解説します。

<!-- v0での<content>によるInsertion Pointsの決定 -->
<template>
  <style>
    ::content input {
      background: skyblue;
    }
  </style>
  <div>
    <content select=".class-name"></content>
    <content></content>
  </div>
</template>

<form-container>
  <input class="class-name" type="text">
  <button>Button</button>
</form-container>

form-container で囲まれた input と button は、それぞれ form-container の content に挿入されます。挿入先は select 属性に指定するセレクタで決定されていました。

v1からは次のように slot に置き換わります。slot は name 属性で命名可能で、カスタム要素を利用する側から能動的に指定できるようになります。

<!-- v1での<slot>によるSlotsの決定 -->
<template>
  <style>
    ::slotted(input) {
      background: skyblue;
    }
  </style>
  <div>
    <slot name="slot-name"></slot>
    <slot></slot>
  </div>
</template>

<form-container>
  <input slot="slot-name" type="text">
  <button>Button</button>
</form-container>

に挿入された要素を参照する疑似セレクタも ::content の子孫から、 ::slotted() になっています。

さらなる詳細について

Shadow DOMのスペックエディタであるGoogleの夷藤さんのWhat’s New in Shadow DOM v1 (by examples)という記事を見ましょう。スペックに合わせて記事も随時アップデートされています。

Custom Elements v1の仕様

Custom Elementsは開発者が任意の要素を再定義可能にする、Shadow DOM同様に重要な機能です。

ES2015 classベースの要素定義とライフサイクルコールバック

Custom Elements v1ではES2015の class 記法を使った定義が推奨されます。もちろん function を使っても同等の実装は可能ですが、ブラウザのサポートも進みつつある class で書いていくのが望ましいでしょう。

<!-- v0でのカスタム要素の定義 -->
<script>
  const FooElement = Object.create(HTMLElement.prototype);
  FooElement.createdCallback = () => { ... };
  FooElement.attachedCallback = () => { ... };
  FooElement.detachedCallback = () => { ... };
  FooElement.attributeChangedCallback = () => { ... };

  document.registerElement('foo-element', {
    prototype: FooElement
  });
</script>

ライフサイクルコールバックも class の constructor() を活かしリネームされているほか、adoptedCallback() が追加されています。

<!-- v1で推奨されるclassを使ったカスタム要素の定義 -->
<script>
  class FooElement extends HTMLElement {
    constructor() { ... }
    connectedCallback() { ... }
    disconnectedCallback() { ... }
    attributeChangedCallback() { ... }
    adoptedCallback() { ... }
  }

  window.customElements.define('foo-element', FooElement);
</script>

adoptedCallback(oldDocument, newDocument) はオーナーとなるドキュメントが変わったタイミングのハンドラです。同一のカスタム要素名が追加先のコンテキストで既に登録されている場合に、フォールバックするなどのユースケースがあるようです。

window.customElements へ

先に出ていますが、カスタム要素を定義する関数も document.registerElement から customElements.define() に変更されています。 customElements はブラウザコンテキストに追加される新たなグローバルオブジェクトです。

customElements.define() の他には次のような関数が提案されています。

// <foo-element>コンストラクタを参照する
const FooElement = customElements.get('foo-element');

// <foo-element>が定義されたタイミングを取得する
customElements.whenDefined('foo-element').then(() => {
  console.log('foo-element is defined');
});

カスタム要素は非同期で処理されるため、HTMLドキュメントに存在するカスタム要素の振る舞いは定義されるまでブラウザは知り得ません。そのため、ロードの遅延などと相まって意図しないガタツキなどを招きます。そのカスタム要素が他の要素をSlotsに追加するようなものであれば、影響はなおさら大きくなります。

それを防ぐには対象のカスタム要素が定義されるタイミングを知る必要があります。customElements.whenDefined() は指定のカスタム要素が定義されるタイミングをPromiseで知らせてくれます。これによって、初期表示ではカスタム要素を非表示にしておいて、ブラウザが評価可能になるタイミングでdisplay: none; を外すといった対応も可能になるでしょう。

Type Extensionの行方

button is="foo-button" のように、元の振る舞いを活かしつつ機能を拡張するType Extensionという機能がv0では検討されていました。この機能については今なお議論が続けられています。複雑な機能を持つ既存要素の振る舞いを壊さないような機能拡張の難しさへの懸念から反対意見も出ており、WebKitは実装を見送っています。行方が気になる人は引き続きウォッチしてみてください。

HTML Imports

HTML ImportsについてはMozillaが2014年に実装を見送っており、昨年（2015年）においても引き続きES6 Modulesによるリソース解決が適切に動作するかどうかを見守る姿勢を見せています。

ブラウザサポート状況

Shadow DOM v1とCustom Elements v1はChromiumにて先行実装されており、Shadow DOM v1はChrome 53とOpera 40から、Custom Elements v1はChrome 54とOpera 41から利用可能です。

またWebKitでも先行して進められており、Shadow DOM v1がSafari 10に実装されている他、Custom Elements v1もSafari Technology Preview 14に実装されており、メニューのDevelop → Experimental Features → Custom Elementsから有効化できます。

• Safari 10.0
• Safari Technology Preview Release Notes

これらが意味するところは大きく、モバイルプラットフォームで大きなシェアを占めるSafariでサポートされることで、モバイルをターゲットとしているプロダクトではWeb Componentsの利用がかなり現実的になってきたと言えます。

デスクトップブラウザについてはFirefoxとEdgeで実装が進むを期待したいところです。EdgeはDeveloper FeedbackでCustom ElementsとShadow DOMに投票しておくと、早く実装してくれるかもしれません

この記事は、「de:code2016」のセッションレポート、日本マイクロソフトエバンジェリスト物江修氏による「モダンWeb:たった今と、ほんの少し未来のはなし」です。講演内容を再現していますが、ニュアンス等伝えきれない場合があるかもしれません。ご了承ください。

モダンWebとは

昨今、様々なところで「モダンWeb」という言葉を聞くが、その定義は曖昧で意味するところの範囲が広範囲に及んでいるためではないかと考える。多くの場合、「モダンWeb」という文脈で語られている内容は次の４つの事柄で語られている。

• モダンなWebシステム
• モダンな開発手法
• モダンな標準機能
• モダンなアプリケーション

単にモダンWebアプリケーションと言った場合にはこれらいろいろな意味に捉えることが多いが、このように四つに分けることができる。このセッションでは、アプリケーションを開発するのに必要な「モダンなWeb標準の機能」、「モダンなWebアプリケーション」に関して触れる。

なぜ「モダンWeb」が話題になっているのか

第一に挙げられることは「時代の要求」。具体的には以下の3つが挙げられる。

• Web技術の進化
• コンテンツのリッチ化
• クライアントの多様化

Web技術で作るリッチなUIは昔から存在していたが、以前はFlashなどのプラグインを利用したいわゆるRIA(Rich Internet Applications)のほうが優勢だった。その後、Ajaxでデータを取得し、そのデータを使って部分的なUIの更新が可能になり、jQuery UIなどのUIライブラリによる開発生産性の向上、そしてHTML5の登場によって、プラグインで行っていたことがWebの標準技術だけで作ることが可能になった。これがWeb技術の進化である。

そしてスマートフォンから始まったFlashの衰退が進み、今までFlashで行っていたような要求をWebコンテンツ側にやってくるようになり、コンテンツのリッチ化が始まった。

スマートフォンを始め、PCブラウザー以外の様々なものがインターネットに繋がり、クライアントが多様化した。

この「クライアントの多様化」はサーバーサイドの形態にも影響を与え、その影響が、Webブラウザー上で動くアプリケーションにも影響を与えたという状況になっている。具体的にどういうことなのか。

黎明期のWebアプリケーションは、リクエストされたページを単純にレスポンスするというもの。ちなみに一番最初のWebサーバーはティム・バーナーズ・リーが作った「CERN Httpd」で、1991年にニュースグループで公開されたが、翌年に作られた「NCSA Httpd」ではCGIがサポートされ、動的ページが作れるようになった。ご存知の通り、このサーバーサイドで処理をして、処理結果をページで返すWebアプリケーションは広く使われている。

さらに、新しいクライアントとして携帯電話が現れる。NTT Docomoから始まった携帯電話は、それまでWebのクライアントというと、PCブラウザかゲーム機くらいで、いずれも机に座って使うようなものだった。

しかし、携帯電話は持ち歩き、行動に必要な情報を得るためのツールとして機能するモビリティという考え方が生まれた。

今までとは利用用途が異なる、サーバーではデバイスに応じた専用のコンテンツを作る必要があるなどコンテンツを作っていくには困難な状況だった。

やがて、スマートフォンに代表されるスマートデバイスが現れます。これらは、PCブラウザー用のコンテンツを同じ様に処理することができたので、わざわざ専用のコンテンツを用意しなくても済む。問題は、画面サイズに応じて表示を切り替える必要があり、同時期に出てきたHTML5関連技術であるCSS3を使ったレスポンシブWebデザインで、こうした技術を吸収することができた。

さらにスマートフォンは、サーバーサイドの処理にさらに大きな変化をもたらした。

Webアプリケーションの登場です。サーバにリクエストを投げるが、必要とするのはページではなくデータでした。この影響を受け、Webサーバーに必要な技術は、データを返す「API」が重要になった。

現在では、クライアントデバイスの性能とWebブラウザーの機能も数段上がり、処理性能ではネイティブで作られたアプリケーションと同等なことができるようになった。

SPA(Single-page Application)

単一ページによるWebアプリケーションであるSPAの特徴は、以下が挙げられる。

• 画面遷移はDOM操作
• ページのリフレッシュは不要
• リッチなエクスペリエンス

SPAにするメリットもいくつかある。例えば、サーバーサイドを「サービス化」することによって、多様化していくクライアントにも対応できるようになる。つまり、サービスをどこにでも提供できポータビリティを上げることができる。

現在のようにクライアント技術の進化が劇的に早い（言い換えると、陳腐化する速度も早い）状況下でもSPAは有効だ。クライアントとサーバーのロジックを物理的に別けることで保守性を上げることができるから。さらに分業においては、サーバーサイドを開発する人間、クライアントサイドを開発する人間で、やるべきことに集中できるということが挙げられる。

プログラミングスタイルの変化

SPAの登場によつてプログラミングのスタイルも少なからず変化している。Ajaxなどの非同期処理を行う場合、処理の単位はサーバーサイドの動作と必ずしも一致せず、処理の順番やタイミングもまちまちになる。それらを適切にハンドリングして画面に描画する必要がある。

さらに、ユーザーアクションの開始が、いわゆるPull型（サーバにリクエストするという意味で）だったが、WebRTCやWebSocketsの登場にによって、突発的に開始されるPush型（サーバからクライアントに通知する）可能性もある。

非同期処理の完了であるが JavaScriptではイベント通知で行われる。また、今まではサーバーロジックで行われていた処理をクライアントで行うケースも出てくるので、1つの完結する処理を行う場合、複数回サーバーとやり取りする必要がある。よく「コールバック地獄」ということに陥る。

不規則に発生するイベントを適切にルーティングしつつ、状態を把握し、かつ処理全体を制御する仕組みが必要で、こういった制御を行うために、JavaScriptのライブラリやフレームワークが様々な機能を実装し提供している。

そして、最新のモダンブラウザーがサポートしつつあるECMA Script2015や2016にも、こうした機能が標準で用意されようとしている。つまりイベントのフロー制御方法は

• Promise(ES2015)
• async/await(ES2016)
• Generator/yield(ES2015)

Promiseは非同期処理を抽象化したオブジェクトでPromiseパターンで非同期処理を行う。async/awaitは、Promise とGeneratorの糖衣構文で、そのGenerator/yieldは、反復子 (イテレータ )の生成元で、実行環境を維持したま中断・再開が可能となる。

SPAでは画面のレンダリングも従来のサーバーサイドの処理をメインしたものとは異なる。

SPA以前のサーバーサイドでページが生成されるタイプのWebアプリケーションでは、画面データの成形もサーバーサイドで行われていましたが、SPAではその部分をクライアントサイドで行うことになる。

素直に書くなら、エレメント一つひとつのインスタンスを取得して、各々データをセットする所謂「Glue code」を書く（”グルー”とは糊のこと）ことになる。だが、これだとエレメント変更に関わるUI仕様があるたびにコードまで修正する必要がありメンテナンスが大変だし、いちいちデータを入れるためだけのコードを書くということ自体が非効率。

データバインディング

そこで出てきたのがUIへのデータバインドです。 マークアップにUIとデータの関係を記述しておくと、JavaScriptフレームワークがよしなにデータをセットしてくれるという仕組みです。 こうすることで、データと画面、いわゆる ModelとViewの関係を1:1に紐づけ、構造的には明確に分け部品化することが可能になった。

“バインド”とあるように、ModelとViewの関係を保持します。つまり、モデルもしくはビューに変更が発生した場合、その変更が一方向、あるいは双方向に反映されます。Modelの変更のみかViewに反映されるのが1Wayバインドで、双方向に変更が伝わるのが2Wayバインドです。

まとめるとモダンなWebアプリケーションとは

• SPA
• リアクティブな動作
• M-V-Whatever

少し先のWebアプリケーションの技術的コンセプト

ここからは、ここ数年提唱されているWebアプリケーションの技術的コンセプトについて紹介します。

• Web Components
• Progressive Web Apps
• WebAssembly

Web Components

まずは「Web Components」です。これはWebをコンポーネント化する仕組みで、2013年のGoogle I/Oで紹介された。実は、Webをコンポーネント化するという仕組みは、これが最初ではなく、マイクロソフトも1998年にHTMLコンポーネントというものを提案したし、Mozillaも2001年にXBLと2007年にXBL2というのを提案した。

このコンポーネント化のメリット、目的について

Webのアプリケーションは、他のソフトウェア・アプリケーションと同様に複雑になり、今ではリリース製品の開発に大勢が協力して取り組むことは珍しくなくなった。少しでも効率化を図るには、関係者やシステム間の重複が最小限になるように開発作業を分割する正しい方法を見つけることが重要になる。そのための方法としてコンポーネント化がある。複雑なシステムでも、機能を分割していけば、単純化することができる。全体をある程度の機能単位に分割する、つまりはコンポーネント化だ。

Web Componentsの目標は、HTML、CSS、JavaScriptの関連グループを分離し、単一ページのコンテキスト “内” で共通関数を実行することで、複雑さを軽減することだ。

この Web Components は、複数の API を組み合わせるか、それ単独を使用して実現する。 しかし、すべての Web ブラウザーがその API をサポートしているわけではないので、Polyfill 用のライブラリーが用意されています。

そしてこちらがWeb Componentsを構成する要素です。

• HTML Templates
• Shadow DOM
• Custom Elements
• HTML Imports

現在のサポートの状況はこのようになっています。

※ 既定では動作しない

Progressive Web Apps

これはモバイル Web アプリ向けのコンセプトで、具体的には、高性能のモバイルWebブラウザー向けにネイティブアプリケーションのようなUXを提供しようというも。去年の「Chrome Dev Summit」のキーノートで発表され話題になったものだ。今年の４月に行われた「Google Developers Summit Tokyo 2016」でも2日のテーマになっていたくらい力を入れている。

Progressive Web Appsに求められる体験をまとめると次の様なもの

• ネイティブアプリケーションのようなUX
  • オフラインサポート: Service Worker
  • プッシュ通知: Web Notifications/Push API
  • ホームスクリーンにアイコンの追加: Web App Manifest
  • バックグラウンド: Service Worker
  • 高速でなめらかなインターフェース: CSS3 Animation

Service Workerは、JavaScriptで実装されているローカルのプロキシ、あるいはApplication Cacheの改良版として利用できる。 いままで Web ブラウザーからサーバーにコンテンツをリクエストする場合、サーバーになげてそれを返していたのが、その間にカスタマイズ可能な Service Worker というのが入って バックグラウンドで動いているので、タブを閉じてもブラウザを終了しても動作しているので、プッシュ通知もうけとれるとこと。httpsでしか動作しない。

Progressive Web Appsを実現する技術のサポート状況は

WebAssenbly

WebAssenblyは、コンパイル済みのバイナリをWebブラウザ上で直接動作させる仕組で、Microsoft、Google、Mozilla、Webkitプロジェクトのメンバーで共同開発されていて足並みが揃っている。

JavaScriptよりもポータブルでロード時間や実行に対するパフォーマンスに優れたアプリケーションを作ることが可能だ。asm.jsの次のステップとしている。

2016/3/14〜16の間にMicrosoft、Google、Mozillaの3社が3DゲームAngry botでの検証結果を各ブログで公開している。

WebAssemblyの実装状況は

ハイブリッドアプリケーションとしての利用

Webアプリケーションが苦手とするところは

• ストアのエコシステムを利用しない
• Webブラウザからはどうしてもアクセスできないハードウェアリソース

そしてこれらの Web アプリケーションのは、ハイブリットアプリとしてパッケージすることにより、ターゲットとなるプラットフォームのリソースや、ブラウザーからはアクセスできないハードウェアの機能を使用できるようになる。 また、アプリストアのエコシステムを利用することができる。

Webフロントエンドの開発リソース

インタラクティブなコンテンツを作ることができるようになったので、開発は非常に大変なものになった。

• JavaScript
  • ライブラリ
  • フレームワーク
  • エンジンテンプレート
  • altJS
• CSS
  • フレームワーク
  • プリプロセッサー
• HTML
  • 軽量マークアップ
• パッケージマネージャ
• タスクランナー
• モジュール管理

Richになったことで多くのライブラリが提供された結果「Chaos」になったのか？と思いがち。そして、ライブラリ/フレームワークの選定として考える必要がある。

• ブラウザサポート
• ベンダーサポート
• 情報
  • ドキュメント
  • 書籍類
• 学習コスト
• 開発生産性
• 機能範囲
• ロックイン
• 運用コスト

特にこの中のロックインですが、ロックインは決して悪いものではなく、優秀なベンダーと一緒になってやっていくこと、コミュニティの力を借りることでむしろ良い状況も作れる。運用コストに関しては、便利なんだけどお金がかかるというものについては考えもの。

標準技術は不変

結局、Webブラウザで動作するのは、HTML、CSS、JavaScriptであり、ブラウザがサポートしていない機能は動かない。技術はあくまでも「手段」でり、そうした技術に対する勉強は大事だが、手段であって目的ではない。目的は、ユーザに対して良いプロダクトを提供すること。たとえば、YouTubeはFlashで作られていたが、HTML5に変わったことに気づいた人はいない、そういうものが良い。

そして、WebはApplicationのプラットフォームになる。どんどん低レベルなAPIを実装することになる。結果、デスクトップと同じ様なアプリケーションを作っていける。こうした変貌は「変化」ではなく「拡張」である。

Googleが開発するWeb ComponentsのライブラリPolymerのバージョン1.1が、2015年8月13日にリリースされました。本記事では、Polymer v1.1のAPIの主要なAPIを解説しつつ、その参考情報を紹介していきます。

また、この記事は「Web ComponentsのこれからーPolymer 0.8、X-Tag、Brick、Bosonic」を事前に読むと理解が深まりますが、これからPolymer v1.1を始めてみるということであれば、本記事単体でも参考にしてもらえればと思います。

Polymer v1.1までの変更点

v0.5からv0.8にかけての差分は前回の記事にて紹介しましたが、その1週間後にv0.9がリリースされ、さらに2週間後にv1.0がリリースされています。

• 0.8 released! – polymer blog
• 0.9 released! – polymer blog
• 1.0 – polymer blog
• 1.1 Release – polymer blog
• Migration guide

v0.8からv1.0にかけてAPIに変更が加えられていますが、v1.0からv1.1へかけては破壊的なAPIの変更はありません。今回は以降で、Polymer v1.x系の主な機能と、参考リソースの紹介をしていきます。

カスタム要素の登録

<dom-module> に <template> と <script> を記述して宣言します。 <script> 内で実行しているPolymer()関数は、 <dom-module> に指定しているID（カスタム要素の名前）を渡し、その他の引数でカスタム要素の振る舞いを決定します。返り値にはカスタム要素のコンストラクタが返却されるので、それを使ってカスタム要素のインスタンスを生成することも可能です。

<link rel="import" href="bower_components/polymer/polymer.html">

<dom-module id="my-element">

  <template>
    <style>
      div { color: red; }
    </style>
    <div>Shadow DOM in My Element</div>
  </template>

  <script>
    var MyElement = Polymer({is: 'my-element'});
  </script>

</dom-module>

v0.8との違いは、カプセル化されるカスタム要素のスタイルを記述する <style> と、Polymer関数を実行する <script> を <dom-module> の中に書くようになった点です。v0.5までの <polymer-element> を彷彿させます。v1.1では <template> の外側に <style> を書いてもスタイルが適用されますが、パフォーマンスは悪く推奨されません。

カスタムコンストラクタ

カスタム要素のコンストラクタを自前で書きたい場合は、Polymer()関数の引数として、factoryImplキーワードと共にコンストラクタ関数を渡します。カスタムコンストラクタによって、引数を渡すことが可能になります。

<script>
  var MyElement = Polymer({
    is: 'my-element',
    factoryImpl: function(foo, bar) {
      // custom constructor is called
    }
  });

  var myInstance = new MyElement('foo', 100);
</script>

このfactoryImplはコンストラクタ関数（ここではMyElement）をnewキーワードと共呼び出した場合のみ実行され、HTMLドキュメントで <my-element> が評価された場合には呼ばれません。

ネイティブ要素の継承

ネイティブ要素を継承したカスタム要素を作る場合は、Polymer()関数の引数にextendsキーワードに継承するネイティブのHTML要素を指定します。v0.5まではカスタム要素の継承もサポートされていましたが、Custom Elementsの仕様としてdocument.registerElement()にカスタム要素名を渡せないのと同様、ブラウザネイティブの要素（inputやbuttonなど）のみを指定できるようになっています。

<script>
  var MyElement = Polymer({
    is: 'my-element',
    extends: 'button'
  });
</script>

ネイティブ要素を拡張するカスタム要素を使うには、extendsに指定した要素にカスタム要素名をis属性に指定します。JavaScriptからインスタンスを生成する場合は、コンストラクタをnewするか、document.registerElement()の第二引数にカスタム要素名を指定してください。

<button is="my-element">My Element</button>

<script>
  console.log(new MyElement() instanceof HTMLButtonElement);
  // => true
  console.log(document.createElement('button', 'my-element') instanceof HTMLButtonElement);
  // => true
</script>

ライフサイクルコールバック

カスタム要素には4つのライフサイクルが存在し、Polymerでもそれらをハンドリングできます。ライフサイクルについてはWeb Componentsを構成する4つの仕様 ー Web Components基礎編という記事の「カスタム要素の挙動を設定する」をセクションにて解説しています。ブラウザネイティブではcreatedCallback・attachedCallback・detachedCallback、attributeChangedCallbackの4つが定義されていますが、PolymerではCallbackが省略されている他、readyというShadow Root配下のDOM構築が完了したタイミングで発火されるハンドラも定義できるようになっています。

<script>
  Polymer({
    is: 'my-element',
    created: function () {
      console.log('my-elementが生成されました');
    },
    attached: function () {
      console.log('my-elementがHTMLドキュメントに追加されました');
    },
    detached: function () {
      console.log('my-elementがHTMLドキュメントから切り離されました');
    },
    attributeChanged: function (name, type) {
      console.log('my-elementの' + name + '属性が変更されました');
    },
    ready: function () {
      console.log('my-elementのDOM構築が完了しました');
    }
  });
</script>

ハンドラの実行順序をまとめると以下のようになります。

1. createdコールバック
2. readyコールバック
3. factoryImplコールバック
4. attachedコールバック
5. (detachedコールバック)

behaviorsを使った振る舞いの制御

カスタム要素の振る舞いを制御するには、これまでのようにPolymer()に直接ハンドラなどを指定するほか、behaviorsにプロトタイプとなるようなオブジェクトを渡すことでも可能です。オブジェクトで定義できるのは先程登場したライフサイクルコールバック、後述するデフォルト属性やプロパティ、オブザーバー（observer）、イベントハンドラの登録（listener）です。

<script>
var MyBehavior = {
  ready: function() {
    console.log('DOM is ready');
  }
};

Polymer({
  is: 'my-element',
  behaviors: [MyBehavior]
});
</script>

見ての通り、behaviorsにはオブジェクトを配列で指定することが可能です。複数指定されてハンドラが重複する（例えば、複数のオブジェクトでreadyが定義されている）場合は、配列上で後から出現するオブジェクトが優先されます（つまり右辺が優先されます）。

カスタム要素のデフォルト属性

カスタム要素のデフォルト属性は、引数のhostAttributesに定義します。hostAttributesに指定した属性とその値は、カスタム要素の属性のデフォルト値になります。

<script>
  var MyElement = Polymer({
    is: 'my-element',
    hostAttributes: {
      role: 'navigation'
    }
  });
</script>

この時 <my-element> は、デフォルトで <my-element role="navigation"></my-element> として評価されます。

カスタム要素のプロパティ

カスタム要素のプロパティは、引数のpropertiesに定義します。プロパティ名をキーに、typeやvalueなどの属性を渡すことでプロパティの特徴を定義します。簡略化された形としては、propertyName: typeという指定も可能です

<script>
  Polymer({
    is: 'my-element',
    properties: {
      foo: {
        type: Number,
        value: 0,
        observer: 'fooChanged'
      }
      bar: {
        type: String,
        computed: 'computeBar(foo)'
      }
    }
    fooChanged: function(newValue, oldValue) {
      // ...
    },
    computeBar: function(foo) {
      return String(foo + 100);
    }
  });
</script>

ここではfooとbarの2つをmy-elementのプロパティとして定義していますが、それぞれobserverとcomputedという属性を渡しています。

オブザーバー関数を指定するobserver

observerはプロパティの変更を監視するオブザーバー関数を指定する属性です。ここではfooChangedという関数を定義しているので、関数名を文字列で渡しています。v0.5まではpropertyNameChangedといったような命名規則を用いてオブザーバー関数を定義していましたが、v1.1においてその機能はありません。監視する関数には引数として、変更後の値（newValue）と変更前の値（oldValue）が引数と渡されるので、前後値を利用することができます。

コンピュート関数を指定するcomputed

computedはプロパティの値を動的に算出するための関数を指定する属性です。observer同様に関数名を文字列で渡しますが、ここではbarプロパティに対しcomputeBar(foo)という値を渡しています。この記述によってcomputeBar関数にはfooプロパティが引数として渡され、barの値は関数が返却する値を参照します。

HTML属性に反映するかどうかを指定するreflectToAttribute

プロパティの値に変更があっても通常はHTML属性に反映されませんが、reflectToAttributeにtrueを指定するとHTMLの属性も更新されるようになります。

<script>
  Polymer({
    is: 'my-element',
    properties: {
      foo: {
        type: String,
        reflectToAttribute: true
      }
    },
    ready: function() {
      this.foo = 'Hello!';
      // this.setAttribute('foo', 'Hello!');と同等の振る舞いが得られる
    }
  });
</script>

この時、readyの関数が実行されたタイミングで <my-element></my-element> は <my-element foo="Hello!"></my-element> となり、setAttribute('foo', 'Hello!')を実行したときと同様の振る舞いが得られます。

イベントハンドラの登録

v0.5以前まではイベントハンドラの登録をブラケットを使って宣言的に定義していましたが、v1.1からはブラケットを使わなくなった他、listenersプロパティにイベントとそのハンドラをハッシュ形式で定義が可能です。

<dom-module id="my-element">

  <template>
    <button on-click="clickHandler">Button</button>
  </template>

  <script>
    var MyElement = Polymer({
      is: 'my-element',
      listeners: {
        'tap': 'myElementTapHandler'
      },
      clickHandler: function(e, detail) {
        // button click handler
      },
      myElementTapHandler: function(e, detail) {
        // my-element tap handler
      }
    });
  </script>

</dom-module>

ジェスチャーイベントのハンドリング

先程のサンプルでtapというDOMネイティブには存在しないイベントに対してmyElementTapHandlerというハンドラを登録していますが、Polymerは自前で実装するにはやや面倒な4つのイベントをサポートしています。

• down: マウスや指によって要素が押下された時
• up: マウスや指が押下後に離された時
• tap: downとupが連続して発生した時
• track: マウスや指が押下されたまま移動した時

それぞれのイベントのハンドラに渡されるイベント引数のdetailプロパティには様々な付加情報が渡されます。詳しくは公式ドキュメントを確認してください。

カスタムイベントの発火

fireという関数を実行することで、ホスト要素を呼び出し元オブジェクトとしてカスタムイベントを発行することが出来ます。引数にはカスタムイベント名と、ハンドラのdetailプロパティに渡すデータを指定します。

<dom-module id="my-element">

  <template>
    <button on-click="clickHandler">Button</button>
  </template>

  <script>
    var MyElement = Polymer({
      is: 'my-element',
      clickHandler: function(e, detail) {
        this.fire('foo', {
          bar: 100
        });
      }
    });
  </script>

</dom-module>

<my-element></my-element>

<script>
  var myElement = document.querySelector('my-element');
  myElement.addEventListener('foo', function(e) {
    console.log(e.detail.bar);
    // => 100
  });
</script>

ここでは <my-element> のボタンをクリックした時にfooというカスタムイベントを発行し、付加データとして{ bar: 100 }という値を渡しています。

データバインディング

データバインディングは以前と同様にカーリーブラケット{{}}およびスクエアブラケット[[]]で指定します。ブラケットではプロパティおよびコンピュート関数を評価することが可能で、v0.5まで有効だった演算子などはサポートされていません。

<dom-module id="my-element">

  <template>
    <input value="{{foo}}" type="text">
    <input value="[[bar]]" type="text">
  </template>

  <script>
    Polymer({
      is: 'my-element',
      properties: {
        foo: String,
        bar: Number
      }
    });
  </script>

</dom-module>

ここでは<my-element>のプロパティとして定義しているfooやbarを、 <input> のvalueにバインディングしています。これによってfooやbarの値に変更があると、<input>に自動で反映されます。

カーリーブラケット{{}}とスクエアブラケット[[]]

カーリーブラケット{{}}とスクエアブラケット[[]]の差は、データバインディングの方向が一方向に制限されるかどうかの違いです。{{}}のデータバインディングは双方向か一方向かが記述によって変わりますが、[[]]は一方向のみであり参照しているプロパティを受け取るのみです。

カーリーブラケット{{}}で指定した際にバインディングの振る舞いを決定するのは、プロパティのnotifyフラグとreadOnlyフラグです。

<script>
  Polymer({
    is: 'my-element',
    properties: {
      foo: {
        type: String,
        notify: true
      },
      bar: {
        type: Number,
        readOnly: true
      }
    }
  });
</script>

notifyフラグはプロパティの変更をホスト要素に通知するかどうか、readOnlyフラグはプロパティが読み取り専用かどうかを決定します。この例ではnotify: trueなので、 <my-element foo="{{value}}"></my-element> としたときにfooに変更があるとvalueへ値が反映されます。

ネイティブ要素との双方向データバインディング

ネイティブ要素との双方向データバインディングも target-prop="{{hostProp::target-change-event}}" という構文でサポートしています。ここでは<input>に入力された値に括弧を付与して<div>に埋め込んでいます。

<dom-module id="my-element">

  <template>
    <input value="{{foo::input}}" type="text">
    <div>{{computeBar(foo)}}</div>
  </template>

  <script>
    Polymer({
      is: 'my-element',
      properties: {
        foo: {
          type: String
        }
      },
      computeBar: function(foo) {
        return `「${foo}」`;
      }
    });
  </script>

</dom-module>

入力された値を参照するタイミングはinputイベントで、バインドするホストプロパティはfooなので、 input value="{{foo::input}}"> になります。これによって、ネイティブ要素のプロパティからカスタム要素へのプロパティへのデータバインディングが行われます。

属性とのデータバインディング

属性に対してデータをバインディングするには以下のように$=を使い、ブラケット{{}}にはこれまでと同様にカスタム要素のプロパティやコンピュート関数を記述します。

<template>
  
  <!-- Attribute binding -->
  <my-element selected$="{{value}}"></my-element>
  <!-- results in <my-element>.setAttribute('selected', this.value); -->

  <!-- Property binding -->
  <my-element selected="{{value}}"></my-element>
  <!-- results in <my-element>.selected = this.value; -->
  
</template>

プロパティとのデータバインディングには <my-element foo={{value}}> と記述することでdocument.querySelector('my-element').foo = valueを振る舞いますが、HTMLの属性にバインディングするためには <my-element foo$={{value}}> のように$=で指定することで document.querySelector('my-element').setAttribute('foo', value) が動的に実行されます。

ネイティブの属性であるclassやstyleには、次のように$=でバインディングすることが可能です。

<!-- class -->
<div class$="{{foo}}"></div>

<!-- style -->
<div style$="{{background}}"></div>

<!-- href -->
<a href$="{{url}}">

<!-- label for -->
<label for$="{{bar}}"></label>

<!-- dataset -->
<div data-bar$="{{baz}}"></div>

HTML上の属性名とDOMのプロパティ名が異なる場合には留意が必要でしょう。data-*の場合、data-fooへの実際のプロパティはelement.dataset.fooとなるため、data-foo={{bar}}ではバインディングできず、element.setAttribute('data-foo', bar)となるdata-foo$={{bar}}を使う必要があります。

Templateのリピート

配列のデータは <template is="dom-repeat"> を使ってリピートし、要素ひとつひとつを参照することが出来ます。以下はis="dom-repeat"を使って配列を展開しているサンプルです（公式より引用）。

<dom-module id="employee-list">

  <template>
    <div> Employee list: </div>
    <template is="dom-repeat" items="{{employees}}">
      <div># <span>{{index}}</span></div>
      <div>First name: <span>{{item.first}}</span></div>
      <div>Last name: <span>{{item.last}}</span></div>
    </template>
  </template>

  <script>
    Polymer({
      is: 'employee-list',
      ready: function() {
        this.employees = [
          {first: 'Bob', last: 'Smith'},
          {first: 'Sally', last: 'Johnson'}
        ];
      }
    });
  </script>

</dom-module>

<template is="dom-repeat"> に加えて展開したい配列をitems属性で指定します。配列の要素の数だけ <template > の内部が繰り返されますが、この中では要素を表すitemと配列のインデックスを示すindexという二つの変数を参照できます。

itemsで参照している配列に変更を加える場合には、インスタンスの関数をそのまま使うのではなくPolymerのインスタンスが備えている専用の関数を使います。例えばこのサンプルのemployeesに値を追加する場合は、 this.employees.push({...})ではなくthis.push('employees', {...})とする必要があります。pushの他にはpop、splice、shift、unshiftも同様です。これらの関数を使わないと、配列への変更が検知されずに再描画されません。

Polymerのデータバインディングの更なる詳細についてはData binding – Polymer 1.0を参照してください。

Polymer内部で行うDOM操作

<dom-module>内部のDOMの操作を行う場合は、Shadow RootのDOM APIではなく専用のインターフェースが用意されています。

IDが与えられている要素の参照

要素に対してIDが与えられていると、this.$.idという形で自動的に参照が生成されます。これはv0.5まで存在していた機能なので、馴染みのある人もいるかと思います。

<dom-module id="my-element">

  <template>
    This is my-element <span id="foo"></span>!
  </template>

  <script>
    Polymer({
      is: 'my-element',
      ready: function() {
        this.$.foo.textContent = this.foo;
      }
    });
  </script>

</dom-module>

また、動的に生成された要素を参照する場合はthis.$$(selector)という関数が用意されています。これにCSSセレクタを渡すと、セレクタにマッチする最初の要素が返却されます。

Polymer.dom()を使ったDOM操作

Polymer内部のDOM操作を行う場合は、Shadow Root配下の要素のDOM APIを直接実行するのではなく、Polymer.dom()という専用のAPIが用意されています。Polymer.dom()の引数にはNodeを渡し、返却されるオブジェクトには、ネイティブのDOM APIと同等の振る舞いをするAPIが用意されています。いずれもDOMのAPIと同じ命名と引数で設計されていますが、サブセットとして用意されているに過ぎず、完全に互換性があるわけではないことに注意してください。

親子関係

• Polymer.dom(parent).childNodes
• Polymer.dom(node).parentNode
• Polymer.dom(node).firstChild
• Polymer.dom(node).lastChild
• Polymer.dom(node).firstElementChild
• Polymer.dom(node).lastElementChild
• Polymer.dom(node).previousSibling
• Polymer.dom(node).nextSibling
• Polymer.dom(node).textContent
• Polymer.dom(node).innerHTML

クエリ

• Polymer.dom(parent).querySelector(selector)
• Polymer.dom(parent).querySelectorAll(selector)

コンテンツの参照

• Polymer.dom(contentElement).getDistributedNodes()
• Polymer.dom(node).getDestinationInsertionPoints()

属性の操作

• Polymer.dom(node).setAttribute(attribute, value)
• Polymer.dom(node).removeAttribute(attribute)
• Polymer.dom(node).classList

Polymer.domから行う追加や削除といったDOM操作は、パフォーマンスを考慮し遅延して実行するようになっています。そのため、操作後のノードの座標やgetComputedStyle()を使ったスタイルの取得をする場合は、操作をPolymer.dom.flush()を使って適時実行し、反映します。

カスタム要素のスタイリング

CSSのスタイリングは、これまでと同様にShadow DOMをスタイリングする記法が適用されます。PolymerはShadow DOMの実装状況で振るまいが変わらないように、Shady DOMという軽量なポリフィルを採用しているため、CSSセレクタをネイティブと同様に書くことはできません。

例えば、<content>を参照する::contentセレクタです。Shadow DOMがブラウザネイティブに実装されていれば単一でも評価されるはずですが、Shady DOMの互換性として::contentセレクタには何らかの親セレクタを指定する必要があります。これは ::content .bar と記述された場合にShady DOMで実現しているスコープを再現できなくなるためです。この場合、 .foo > ::content .bar と書く必要があり、実際には .foo > .bar のように評価されます。

<dom-module id="my-element">

  <template>
    <style>
      :host {
        display: block;
        border: 1px solid red;
      }
      .foo > ::content .bar {
        background: orange;
      }
    </style>

    <div class="foo"><content></content></div>
  </template>
  
  <script>
    Polymer({
      is: 'my-element'
    });
  </script>

</dom-module>

まとめ

Polymer v1.1の主な機能について解説しました。v0.5 → v0.8 → v0.9 → v1.0…とAPIに多くの変更が加えられてきましたが、メジャーリリースになったことで、これまでのような大きな変更は（ おそらく ）なくなるでしょう。

最後に、今年9月の14日〜15日にオランダのアムステルダムにて開催されたPolymer Summit 2015にて、参考リソースが多く公開されたのでそれを紹介します。

Polymer Codelabs

Polymer Codelabsは、Polymerを使ったアプリケーションを作成していくチュートリアル集です。Polymer Summitに合わせて11個のチュートリアルが公開されています。こちらも英語ですが、環境のセットアップから丁寧に解説されています。

セッション動画リスト

Polymer Summit 2015の各セッションはすべて以下のチャンネルで配信されていますので、興味のある方は是非チェックしてみてください。

後編である今回は、Extensible Webの現在、そしてWeb技術の未来にフォーカスしたお話になります。Extensible Webの概要や、Extensible Web以前からあるWebの問題点について知りたい方は、前編をご覧ください。

HTML5は（ついに）モジュール化される

白石 では、Extensible Webの考え方が提唱されてから2年が過ぎたわけですが、どのような変化が起きつつありますか？まずは皆さん、思いついたものから教えていただけると嬉しいです。

ダニエル 最近の話で言うと、HTML5の仕様がモジュール化されます。例えばTimed Media Working Groupというワーキンググループが提案されていますが、もともとはHTML5の一部でした。このように、専門的なグループに分かれて仕様策定が進められるようになろうとしています。

白石 Extensible Webは、標準化の話とも密接に関わっているかと思うので、詳しく教えて下さい。HTML5.1がバラバラになっていくということでしょうか？

ダニエル そうです。まだ詳細は決まっていませんが、今後仕様書も分割されていきます。ちょうど、CSSがバージョン3になって、多数の仕様書に分割されて、それぞれメンテナンスされるようになったのと似た感じになるでしょう。

また、ワーキンググループが分かれていくというだけではなく、もっと開発者が参加しやすくなります。その一つが、Web Incubator Community Groupの作成です。これができたのもつい最近（2015/7/2）ですね。ここは仕様を提案する場というよりは、質問してアドバイスを受けたり、デモを投稿したりと、一般の開発者のサポートが中心になります。

斉藤 これは素晴らしいですね。最近すごく思うのは、仕様書がGitHubに置かれるようになって、別にGitHubが大好きというわけでもないんですが、開発者に見られるサイトNo.1ということで、変更の履歴すらも簡単に見られるようになり、どういう経緯で仕様が変更されていったかが追えるようになったのは素晴らしいと思います。

ダニエル 10月のTPACまでに細かい作業を終えて、TPAC以降にフィードバックをもらいながら改善していくという感じだと思います。

APIの低レベルさはどこまで許容される？

浅井 最近はExtensible Webの流れを受けて、低レベルなAPIを提供して開発者に使ってもらおう、ということを意識するようになりました。例えば最近、センサー類のAPIを作ろうとしているのですが、大きく２つの方向性があるという議論になったんですよ。

一つは光センサーとか、既存のセンサーを抽象化するようなもの。またそれと合わせて、組み込み向けの通信制御のAPIを提供してはどうかというものでした。こちらはまあ、普通ですね。

でももう一つはぶっ飛んでて、Low Level File System APIっていうのを作ってしまってはどうか、と。 UNIXって、/dev 以下のファイルを通じてデバイスにアクセスできるじゃないですか。だったら、ファイルにアクセスできる手段を一つ開発者に与えてあげるだけで、どんなデバイスでも操作できるようになるじゃないか、と。本当に低レベルなものを作りさえすれば、開発者が必要なものを作れるよという考え方です。

でもこれは完全にぶっ飛んでる。だってプラットフォームに思い切り依存するじゃないですか。やり過ぎ感はすごくあるけど(笑)、それをマジメに議論できるようになったというのが、Extensible Webから来る発想なんじゃないかな、という気がします。僕としては、ちょっと低レベルすぎるんじゃないかと思いますが。

白石 そのうち、システムコールとか叩けるAPIが出てきそうですね。

浅井 あまりAPIが低レベル過ぎても、今度は（JavaScriptライブラリによる）パフォーマンスのロスが大きすぎるし、OS依存のAPIを露出するのはよくないという考え方もあるので、どこまで低レベルにいくべきかというのは、今Extensible Webの中で本当に議論していかなくてはならないんじゃないか、という気がします。

「Extensible」なAPIたち

白石 なるほど。ではここでちょっと話を変えて、実際にExtensible Webに関連するAPIといえば何があるんでしょう？まずFetch（※）とか。あと、ServiceWorker（※）もでしょうか。

斉藤 Promise（※）とかもそうだと言っていいんじゃないでしょうか。Promiseの原型になったAPI（Deferとか）は、Extensible Webの提唱以前からありますが。

小松 他には、Object.observe（※）とかもありますね。

浅井 Web Components（※）もそうでしょうね。

ダニエル Web Componentsは便利ですよね。Polymer 1.0が出た時に使ってみましたが、とてもよかった。でも、Polymer自体がものすごく巨大なので、便利さの代償も大きいな、と(笑)。

浅井 Web Components、小規模なプロジェクトならいいですが、大規模で長期的なプロジェクトとかでは、まだあまり使われてないんじゃないでしょうか。 そういう点では、Mozillaはむしろ積極的に使っています。しかも、Firefox OS本体で。本当に大事なAPIは、誰かがガチで使わないと熟成されないので、我々は必ず本番プロジェクトにガンガン入れるんです。

Firefox OS 2.5とかになると、Web ComponentsだけじゃなくてServiceWorkerとかも思い切り使って、アプリケーションのアーキテクチャを大幅に変更しようとしてます。どこよりもServiceWorkerを思い切り使って、悪いところを見つけ出そう、くらいの勢いですね。 ただ、ServiceWorkerをフルに使用して、複雑なキャッシュ処理とかを行うコードを見ていると、これはもう一般のWeb開発者が気軽に触れるレベルじゃないな、と思います。WebGLを生で扱うコードとかもそうですけど。

小松 WebRTCなんかについても、「一般のWeb開発者にとっては、使うのが難しい」という話はよく聞きます。でもWebRTCは、低レベルすぎるという意見もあれば、あれでもまだAPIのレベルが高過ぎるという意見もあって。

もともとはビデオチャットをユースケースとしてAPIを作っていたんだけど、実際にやってみると双方向のビデオチャットだけじゃなくて、例えば監視カメラみたいに「一方向だけ」というユースケースも重要だったりとか、多人数会議とかやるときは映像のネゴシエーションとかもっと柔軟にやりたい、という話が出てくると、実は今のWebRTCでも高レベルすぎると。その議論が、今のORTCに繋がったりしているわけです。しかし、APIのレベルを低くすればするほど、柔軟性は向上するんだけど取り扱いは難しくなって、一般の開発者が触るには難しいものになっていくだろうな…とは感じています。

白石 なるほど…WebRTCみたいな、高度なネットワーク処理を伴うAPIについては、TCP/UDPのソケットを直接触れるような低レベルAPIがあればよさそうですよね。Socket APIとかは既にあるんでしたっけ？

浅井 ありますよ。Firefox OSではよく使われています。

白石 ああそうか、Firefox OSやChrome OSだと、かなり低レベルなJavaScript APIが既に実装されてますよね。Bluetoothとか、シリアル通信とかも可能だったような。

ダニエル BluetoothのAPIは使ってみたんですけど、やっぱりChromeブラウザじゃなくてChrome OSでしか使えないんですよね。ブラウザで（通常のWebアプリで）使いたいとは感じましたが、それは叶っていません。「危険だ」と。

小松 APIのレイヤーを下げていくことと、セキュリティやプライバシーはトレードオフがありますよね。

※ Fetch…ブラウザがHTTPを使用してリソースを取得する操作をAPIとして利用できるようにしたもの。XMLHttpRequestに近いが、よりAPIが洗練されている

※ Web Components…カスタム要素を利用できるようにできるAPI

低レベルAPIとセキュリティ・プライバシー

ダニエル 今お話に上がったように、「低レベルなAPIは危ない」という問題もある。皆さんここはどう考えますか？

白石 僕が今回の対談を準備するにあたって、いろいろ情報を集めた中では、「そういうセキュリティやプライバシーの部分こそ、標準化のリソースを費やすべき点だ」という意見がありました。ひとりのエンジニアが、自分の力だけでセキュリティやプライバシーを完璧に実装することは不可能なので、標準化というプロセスを踏んで様々な知見を集約することで、そういったAPIの安全性を担保するという。

浅井 ただ今の時代、APIだけでセキュリティを担保するのは難しくて、結局はアプリケーションのエコシステム全体でサポートしていかなくちゃいけないんですよね。例えばWebを全てHTTPS化するとか、アプリケーションマーケットでセキュリティレビューが行われるから安全になるとか、ほかの仕組みと組み合わせることで安全性を担保するという形になってきている。

まあ、一方で、そういう他の仕組みで担保してもらえるからエンジニア自身はあまりセキュリティのことを考えなくなっている…というのもあると感じています。もし低レベルのAPIが使えるようになるなら、実際躊躇なく開発者は使うわけですよ。Firefox OSでもふんだんに使われています。セキュリティレビュー前提でね。でも、そのセキュリティレビューが、どのエコシステムでも行われるわけではない。もしそういうAPIが、（セキュリティレビューのない）一般のWebコンテンツでも使えるようになったらまずいんです。

エコシステム全体で安全性を保っているのに、エコシステム抜きでAPIだけ持ってきて使えるようにしてしまうと、安全でなくなってしまう。そこをどうやって担保していけばいいのかな、というのはすごく難しく感じています。

白石 HTTPSが前提だったり、Firefox OSみたいな環境の上でサンドボックス化されたアプリケーションであることが前提だったりとか、APIを取り囲む様々なコンテキストだったり環境を含めてこそセキュリティが担保されるのであって、APIだけ切り出して安全性を担保するというのは難しいということですね。

斉藤 なるほど… 正直、「ServiceWorkerがHTTPSのみになりました」と聞いた時「なんだとコノヤロウ」と思ったくらいなんですが(笑)。よくよく考えてみると「そうだよね」と納得は出来るんですが、一方で「誰がそのSSL証明書代払うねん」という感じでもあります(笑)。

浅井 MozillaはHTTPSの無料化を推進しようとしていますけどね。

白石 そうですよね、頑張ってくださいよMozillaさん！世界中がMozillaに期待してます(笑)！

でも、ServiceWorkerはHTTPSオンリーです、というのは少し乱暴な感じも受けるのですが。今後、Extensible Webの思想に則ったAPIがどんどん現れるとして、「とりあえず危ないかもしれないからHTTPS限定にしておこう」という感じになっちゃわないんでしょうか？

斉藤 まあ、流れとしてはWebは全部HTTPSにしていこうという感じですしねえ…

小松 そうそう。iOS9のWebViewは、デフォルトではHTTPS接続しかできなくなるしね。

ダニエル 標準化のほうでも、実際そういう流れはあります。「Secure Contexts」というドキュメントがあって、「こういう場合はHTTPS接続が必要」というシチュエーションを列挙しています。 これによると、センシティブなデータやセンサーデータにアクセスするAPIは全て対象となっていますので、（今まで非HTTPS環境でも利用できていた）Geolocation APIなども、将来的にはHTTPS限定になるかもしれません。

世界は、開発者からのフィードバックを求めている

白石 ここまでは、Extensible Webを中心として、Webの過去や現在についてお話いただきました。では、未来のWeb技術はどうなるんでしょう？

ダニエル 簡単に言うと、低レベルなAPIが増えて、高レベルなライブラリが増える、ってことじゃないかと思います。

斉藤 一般の開発者や企業もライブラリを作るようになり、もっと言えば、それで利益を上げる企業が出てきてもいいと思います。今はWebのプラットフォームやライブラリを作っているのって、結局ブラウザベンダ周辺の方々ばかりです。もしそこで利益を上げられる仕組みが出てきたとしたら、もっと一般の企業や開発者がWebのプラットフォームづくりに貢献できるようになるんじゃないかと。今は、あまり貢献できる余地がない。

浅井 （Webプラットフォームへの）貢献という点では、ブラウザベンダの立場から言うと、一番求めているのって開発者からのフィードバックなんですよね。Webブラウザのエンジニアは、フィードバックが欲しくてしかたがないんですよ。自分たちが仕様を書いても、他の人が作って使ってくれないと標準化できないんですから。そこを、どんな方法でもいいから解決したくって、だからこそこんな考え方（Extensible Web）になったという流れもあると思います。

白石 そうですよねえ…前編でいくつか挙がっていた「使われていないAPI」なんて、ほんとに使われてなさそうなので、フィードバックも何もあったもんじゃないですよね。

浅井 そうなんです。少なくとも僕らは、W3Cにインパクトを与えるためにもどんどん開発者は意見をあげていってほしいと思っていますし、ダニエルさんが紹介していたWeb Platform Incubator Groupにも参加してほしいと思っています。Mozillaに限って言えば、Bugzillaに日本語でもいいからガンガンコメント欲しいですね。「英語で書かなくちゃならない」と思って書かない方も多いんですが、翻訳サイトを使って読んでみて、わからなければ日本のエンジニアに質問が来るので。

斉藤 なるほど、そういう貢献であれば、気軽にできそうだし人にも促せそうです。

浅井 わかりにくい英語でフィードバックもらうくらいなら、専門用語満載で日本語で書いてくれたほうがありがたいんです。フィードバックをもらえないことで発生するコストに比べたら、日本語のフィードバックをもらってそれに日本のスタッフが応えるなんて安いもんです。今はそれこそ、縦書きの仕様とかあるじゃないですか。ああいうところって、日本でしか通用しない用語がたくさんある。それを無理に英語にする必要はなくて、そのまま日本語で書いてほしい。

斉藤 そうですよね…「禁則処理」とか英語でどう言えばいいのか、よく考えたら知らない(笑)。

浅井 そういうフィードバックを世界中の開発者がくれる、という未来を僕らは目指しているんです。それに、Extensible Webが進むことで、例えばライブラリやミドルウェアをビジネスにするような企業も出てきたとしたら、そういう企業ってブラウザベンダとの協業にも本気なので、更にフィードバックが熱くなって嬉しいし。

例えば3Dにしても、UnityとかUnrealとか大きな企業がガンガンフィードバックをくれるので、WebGLやasm.jsも —— 今は WebAssemblyの方向に向かっていますが —— どんどんよくなっていったわけですし。

小松 確かに、ビジネスで使われると急激にフィードバックが貰えるようになりますよね。

斉藤 「趣味」のレベルと「ビジネス」のレベルだと、フィードバックするモチベーションもぜんぜん違うかもしれませんね。

小松 そうそう。趣味でやってる時って、例えバグに遭遇したとしても「このバグは仕様である」って済ませちゃう(笑)。

斉藤 「ま、いっか」で済ませちゃいますよね(笑)。Web技術の進化がビジネスに直結するのであれば、フィードバックのモチベーションは確実に高まると思います。

今あえて問う: Web技術の進化は求められているのか？

白石 ここで一つ、ちょっと刺激的に聞こえるかもしれない問題提起をさせてください。 Web技術の進化って、今そんなに求められているのでしょうか？ 現状で言うと、Web技術って主にデスクトップブラウザで使われていて、モバイルはネイティブでいいよね、と世間に認知されている感覚が僕としてはあって。 しかも、デスクトップは進化が停滞していて、イノベーションはモバイルアプリで起こっている。WebのAPIをどんどん拡充していっているけど、それで喜んでいる人ってどれくらいいるのかな？と。

ダニエル 確かに…最近そういう議論がありましたね。ppk（※）を中心として、「Webは一年くらい開発を止めておこう」という発言がありました。

斉藤 僕もppkの発言は読みました。普通、僕らの開発でも、2年も経てばたくさん技術的負債が溜まっていってしまうものなのに、Webは壊れたままでどんどん新しい機能を追加していこうとしている。「一旦止まってしまうと死んでしまう」「止まることは後退することだ」というある種の強迫観念のようなものがあるのかもしれません。

浅井 実際には（Webの進化は）長い間止まってましたけどね(笑)。

白石 (HTML)4と5の間ね。

斉藤 あの（進化が止まっていた）悲しさを繰り返しちゃダメだと、みんな思っているんじゃないでしょうか。僕は、Webはなくなってほしくないと思っているので、Web技術の進化は続いてほしいと考えています。ただ白石さんが仰るとおり、モバイルはネイティブでいいじゃん、という流れもあるのは確かです。

白石 僕自身も、モバイルアプリであってもCordovaを使って開発していたりするので、Web技術は進化し続けてほしいと考えてはいます。CordovaやFirefox OSと言ったプラットフォームが今よりもっと力を持てば、先ほど僕が言った問題提起は不要だと思うんですけどね。

浅井 今はiOSやAndroidのシェアが非常に大きいですからね。そこら辺の状況が変わってくれば、Web技術の立ち位置ももう少し変わってくるんでしょうけどね。

また、先ほどあれだけ開発者に「声が欲しいんです」と訴えましたが、一方で仕様を作っているメンバーが念頭に置いているのは、5年10年先まで互換性を保ち、しかもあらゆるプラットフォームで動作することです。最初からこれを念頭に置いたプラットフォームは、人類にとって唯一のものだと思う。だから、5年10年先を見据えて絶え間なく技術を進化させていくというのは、誰かがやらなくてはならないと思っています。

白石 そう考えると、昔の「ユースケースありき」で仕様を決めていくというのは少し無理があったのかな、と思えますね。5年10年経ったら、ユースケースなんて同じなわけがないですし。そう考えても、Extensible Webというのは正しい方向なんじゃないかと思えてきました。

ダニエル そうですね。HTML5の世界は、長らくユースケースベースでした。例えばHTML5に何かを提案しようとすると、Ian Hickson（※）の答えは決まって「あなたのユースケースを教えて下さい」（「What’s your use case?」）でしたし。Extensible Webは、そうしたパラダイムからの脱却という面は少なからずあると思います。 ※ ppk…Peter-Paul Koch氏のこと。著名なWebエンジニアで、QuirksModeというサイトを運営している。

※ Ian Hickson…HTML5を始め、近年の様々なAPI仕様を策定するにあたって中心的な役割を果たしていた人物。相性はHixie。

新たなライブラリ、仕様書の変化 – Extensible Webがもたらしつつある変化とは

ダニエル CSSの方でも、ユースケースありきの考え方から脱却しつつあります。例えば「CSS Houdini」は、ユースケースを考えずにCSSの基盤を公開して、その上に新たな機能を載せていくというアイデアです。

例えば、「新しいセレクタが欲しい」という場合、CSSの低レベルAPIで独自のCSSセレクタを作ったり…ということが想定されています。

小松 正確ではありませんが、「Web ComponentsのCSS版」といえばわかりやすいんじゃないかな。

斉藤 「独自のCSSセレクタを作る」というのを実現するhitch.jsというライブラリはすでにありますね。

白石 （READMEの例を一見して）自分の好きなセレクタを書ける！これはすごい。いやー、未来的な話になってきましたね。

斉藤 CSSにまつわる話で言うと、CSS Element Queryっていうのもありますね。

白石 （こちらもREADMEの例を一見して）ああ、これは使いやすそうですね。メディアクエリで「巨大なif」みたいな感じになるのが防げますね(笑)。

小松 ほんとだ、これは便利そう。

ダニエル ちょっといいですか？今ここで起きていることこそが、Extensible Webが目指す形だと思いました。

これまでは、まず英語でできた仕様書しかなくて、その後コードやデモが整備されるまでは中々APIを理解できない。英語がよく読めない人たちにとってはなおさらです。

でも今ここで起きていたのは、アイデアがコードで示されていて、皆さんは説明よりも先にコードを読んでいました。そして、「これはいい」とか「これは良くない」とかそういう話で盛り上がっていた。

小松 確かに。それに、仕様書にコードスニペットが記載されるという動きも、どんどん広がってますよね。そっちのほうがずっと分かりやすいから。

白石 そうですよねー、WebIDL（※）で示されたインターフェース定義から、どう動くのか想像するのとかって、割としんどかったですからね。そもそもWebIDLの読み方を勉強しなくちゃならない。

斉藤 「仕様書の読み方」みたいな講座があってもいいかもしれませんよね(笑)。

※ WebIDL…W3Cのドキュメントで使用される、Web技術用のインターフェース定義言語（IDL:Interface Definition Language）

Extensible Webから探る、Webの未来

白石 では、最後のトピックとして、Webブラウザの未来を探ってみたいと思うのですが、いかがでしょう？例えば以前、「Webは死ぬか」という対談を行った時に、Googleの及川さんが、「ブラウザコードもコンポーネント化が進んで、必要に応じてコンポーネントがダウンロードされる」という可能性を示唆してくれたのですが。

小松 例えばLinuxディストリビューションを想定してみるのもいいかもしれませんね。Linuxのカーネルに当たるのが現在のブラウザエンジン（のコア部分）で、その他の部分、例えばJavaScriptライブラリや利用頻度がそこまで高くないAPIとかは、パッケージみたいな扱いになるとか。

ダニエル 未来のブラウザという話で言うと、もっと専門的なブラウザが出てくる可能性もあるのかな、と考えています。例えばEspialという会社がありまして、別にここは新しい会社ではありませんが、TV専用のブラウザを作っていて、結構使われています。 こういうブラウザが、TVに関係する機能だけ実装すればいいのと同じように、家電専用のブラウザとか、色んな用途に特化したブラウザが出てくる可能性は大きいと思います。

浅井 ブラウザが様々なデバイスで使われるようになっていくと、そのうちブラウザというのはユーザから見えなくなって、意識されなくなっていく。四角くなくなるとか、UIのないブラウザとかが普通に使われるようになっていく。

斉藤 ブラウザがどこにでもある、って世界ですね。

白石 ただ例えば、ウェアラブルデバイスにブラウザが乗るのは当面ないような気もしますね。パフォーマンスの問題もありますし。

斉藤 それは確かにそうかもしれません。が、何をもってブラウザと呼ぶのか、という話もありますね。例えば最近読んだのは、車通勤している最中に、Mediumの記事を読み上げてほしいという話があって。そのためのAPIを作ってはという話だったのですが、サーバ側でMediumのHTMLを解釈して、音声データだけをダウンロードしてクライアントで再生するようにすれば、HTMLを解釈する「ブラウザ」はクライアント側になくてもいいわけです。このように、Webページを「聞く」という行為、それすらも「ブラウジング」と言えると思います。

白石 なるほど、「ブラウザがどこにでもある」という世界を考えると、逆にブラウザが手元になくてもいいわけですね。HTMLが単なる音声データのためのデータソースになっている。

浅井 そういうサービスを作るにあたっても、Web技術を使うようにすると、特許の問題とかが起きにくいんです。

斉藤 ああ、それはありますね。

浅井 …新しいものを作るときに、エコシステムが広がるのをブロックしてしまう原因を、Webは比較的解決していたり、最初から意識していたりすることが多いので、Web技術が広がってくれると、

白石 広がってくれると？

浅井 より人類は幸せになれます。

白石 話でかい(笑)。〆の言葉としていい感じのフレーズが出たところで、本対談を終わりにしたいと思います。皆様、本日はどうもありがとうございました！

この記事は、連載「基礎からわかるWeb Components徹底解説～仕様から実装まで理解する〜」の第5回目になります。今回は、先日発表されたPolymer 0.8の変更点、MozillaのWeb Componentsへの関わり方やX-Tag、Brick、BosonicといったPolymer以外の周辺ライブラリについて紹介します。

Polymer 0.8のリリース

先日、Polymerのバージョン0.8がリリースされました。

• 0.8 Released! – Polymer Blog

0.8は1.0のリリースに向けたアルファリリースと位置付けられています。APIも正式版への提案として大きく変更が加えられており、これまでとの互換性も保たれていません。既に実践でPolymerを使っていて、0.8へアップデートを行う場合はこれまでのコンポーネントを作り直す必要があります。

アルファ版ということで、ユーザーのフィードバックや再設計を経て、さらなる変更がある可能性もありますが、より完成度の高いライブラリに近づいていくことでしょう。アップデートに伴い、どのような変更があるのかを見ていきます。

ポリフィルライブラリ

これまでポリフィルライブラリとして推奨されてきたwebcomponents.jsですが、以降はwebcomponents-lite.jsが推奨されています。webcomponents.jsとwebcomponents-lite.jsの差はShadow DOMのポリフィルを含んでいるかどうかなのですが、Polymer 0.8ではよりシンプルで軽量な shady DOM というShadow DOMのポリフィルを含んでいるためです。

• webcomponents/webcomponentsjs
• webcomponents/webcomponents-lite

異なる用途でShadow DOMのポリフィルを必要とする場合は別ですが、Polymerを利用するためであれば、webcomponents.jsの重いShadow DOMのポリフィルを含まず、軽量なwebcomponents-lite.jsを選択するのが望ましいと言えます。

軽量化とパフォーマンスの向上

APIの大きな見直し（後述）と抜本的なリファクタリングによって、ライブラリのファイルサイズの軽量化と実行パフォーマンスの向上が図られています。以下はPolymerLabs/benchmarksで試すことができるベンチマークの結果です（Polymer公式サイトより引用）。初期描画までの時間の棒グラフになっており、低ければ低いほど描画までの時間が短くパフォーマンスが良いということになります。

いくつかのデバイス・ブラウザで計測されていますが、いずれも0.5に比べて0.8が数倍高速に動作するという結果が出ています。もとよりWeb ComponentsはHTML ImportsのCustom Elementsの遅延評価されるという性質によるコンポーネントのがたつきやチラつきが問題になりがちですが、最も重要である初期描画までのパフォーマンスが向上されているのは嬉しいところです。

互換性のない大きなAPIの変更

冒頭で述べた通り、0.5以前と互換性はありません。

• About this release – Polymer
• Migration guide – Polymer

リリースノートとマイグレーションガイドを元に主な変更点を見ていきます。さらなる詳細な差分については、公式ドキュメントを確認してください。

カスタム要素の登録

これまでは、<polymer-element>要素を用いてカスタム要素の登録を行ってきました。

<polymer-element name="my-element">
  <template>
    <style>
      div { color: red; }
    </style>
    <div>Shadow DOM in My Element</div>
  </template>
  <script>
    Polymer();
  </script>
</polymer-element>

0.8からは以下のように、<dom-module>を起点にした方法に変更されます。<dom-module>要素のIDに登録したいカスタム要素名（ここではmy-element）を指定し、PolymerコンストラクタでそのIDを参照しています。

<dom-module id="my-element">
  <style>
    div { color: red; }
  </style>
  <template>
    <div>Shadow DOM in My Element</div>
  </template>
</dom-module>

<script>
  var MyElement = Polymer({is: 'my-element'});
</script>

Polymer({is: 'my-element'});の実行より前に、<dom-module>がロードされている必要があります。<style>タグを<template>の外に配置するようになった点にも注意して下さい。要素の継承についても同様にextendsキーワードで行うことができますが、0.5以前では可能であったカスタム要素の継承は廃止され、<button>や<textarea>のようなビルドインのHTML要素のみになっています。また、これまではconstructor属性にコンストラクタ関数名を指定していましたが、0.8では属性が廃止されるとともにPolymer()がカスタム要素のコンストラクタを返却するようになりました。

document.registerElementの第二引数に指定するextendsの値にもカスタム要素名を指定することはできず、コンストラクタ関数の返却もdocument.registerElementが行います。いずれも素の挙動に近い振る舞いになったと言えるでしょう。

カスタム要素のパースの順序

カスタム要素を含むカスタム要素を作成する場合は、内包するカスタム要素が事前に登録されている必要があります。つまり、<child-element>を含む<parent-element>を作成する場合、<child-element>が事前に登録されていなければなりません。

デフォルト属性とプロパティの宣言

カスタム要素のデフォルト属性とプロパティ宣言の方法も変わります。0.5までは以下のように、デフォルト属性は<polymer-element>に、プロパティの宣言はattributesにスペース区切りで指定していました。

<polymer-element name="your-element" attributes="foo bar" role="button" layout horizontal wrap>
  <template>
    <button>Your Element</button>
  </template>
  <script>
    Polymer({
      foo: 0,
      bar: 'Hello!'
    });
  </script>
</polymer-element>

0.8以降は以下のように、Polymer()コンストラクタにhostAttributesやpropertiesを渡すことで宣言します。

<dom-module id="your-element">
  <template>
    <button>Your Element</button>
  </template>
</dom-module>

<script>
  Polymer({
    is: 'your-element',
    hostAttributes: {
      role: 'button',
      class: 'layout horizontal wrap'
    },
    properties: {
      foo: {
        type: Number,
        value: 0
      },
      bar: {
        type: String,
        value: 'Hello!'
      }
    }
  });
</script>

layout、horizontal、wrapといったようなレイアウトに関するカスタム属性も通常のCSSクラスになり、hostAttributesのclassに指定します。また、このレイアウト機能はPolymerのコアから分離されpolymer.htmlに同梱されなくなったので、別途layout.htmlをインポートする必要があります。

オブザーバーの登録

プロパティの値の監視や、宣言的なイベントハンドラ登録といった機能もPolymerの強力な機能のひとつですが、これらにも少々変更があります。

これまでは、fooというプロパティに対してfooChangedというオブザーバー関数を宣言すると命名規則によって自動でバインドされる機能がありました。また、IDを振った要素はthis.$.idという形でコンストラクタ内でノードを参照することが可能であり、それをobserversに定義することでもプロパティの監視が可能でした。

<polymer-element name="your-element" attributes="foo">
  <template>
    <input type="text" id="input">
  </template>
  <script>
    Polymer({
      foo: 0,
      observers: {
        'this.&.input.value': 'inputValueChanged'
      },
      fooChanged: function (oldValue, newValue) {
        console.log('newValue is ', newValue);
      },
      inputValueChanged: function () {
        console.log('this.&.input.value is changed');
      }
    });
  </script>
</polymer-element>

0.8からはこのpropertyNameに対してpropertyNameChangedという関数を定義することで自動バインドされる仕組みと、IDを振った要素がthis.$にぶら下がる機能が廃止されます。これによってプロパティの監視を行うには、以下のように、ブラケットで囲った変数に対し、observer属性にオブザーバー関数を明示的に宣言することになります。

<dom-module id="your-element">
  <template>
    <input type="text" value="{{inputValue}}">
  </template>
</dom-module>

<script>
  Polymer({
    is: 'your-element',
    properties: {
      foo: {
        type: Number,
        value: 0,
        observer: 'fooChanged'
      },
      inputValue: {
        observer: 'inputValueChanged'
      }
    },
    fooChanged: function (oldValue, newValue) {
      console.log('newValue is ', newValue);
    },
    inputValueChanged: function () {
      console.log('inputValue is changed');
    }
  });
</script>

暗黙的にオブザーバー関数がバインドされる分、直感的に解り難い機能であったので、このように明示的な宣言方法になるのは嬉しいところです。

イベントハンドラの登録とデータバインディング

ブラケット{{}}によるデータバインディングや、イベントハンドラの登録もPolymerお馴染みの機能ですが、これらにも少々変更があります。

<polymer-element name="our-element">
  <template>
    <input type="text" value="{{firstName}}">
    <input type="text" value="{{lastName}}">
    <button on-click="{{onClick}}">Say full name</button>
  </template>
  <script>
    Polymer({
      onClick: function () {
        alert("{{firstName + ' ' + lastName}}");
      }
    });
  </script>
</polymer-element>

0.8からは{{}}内の式の評価はサポートされなくなります。

この例で言えば、"{{firstName + ' ' + lastName}}"のような表現はできなくなります。代わりにcomputedを用いて、式評価後の値を参照するプロパティを宣言する必要があります。これは0.5以前とは異なり、0.8からはpropertiesの配下に定義する属性になることに注意してください。

同じく、{{}}を使ってon-click="{{onClick}}"のように定義していたイベントハンドラの登録は、カーリーブラケットを使わずに記述します。

<dom-module id="our-element">
  <template>
    <input type="text" value="{{firstName}}">
    <input type="text" value="{{lastName}}">
    <button on-click="onClick">Say full name</button>
  </template>
</dom-module>

<script>
  Polymer({
    is: 'our-element',
    properties: {
      firstName: String,
      lastName: String,
      fullName: {
        type: String,
        computed: 'computeFullName(firstName, lastName)'
      }
    },
    computeFullName: function (firstName, lastName) {
      return firstName + ' ' + lastName;
    },
    onClick: function () {
      alert('{{fullName}}');
    }
  });
</script>

このようにfullNameにcomputed: computeFullName(firstName, lastName)とすることでcomputeFullNameの実行結果を参照することが可能です。

DOMの操作

Polymer内でDOM操作を行う場合、通常のShadow Rootから実行するDOMのAPIではなく、Polymer.domという専用のAPIを使う必要があります。

• Polymer.dom(parent).appendChild(node)
• Polymer.dom(parent).insertBefore(node, beforeNode)
• Polymer.dom(parent).removeChild(node)
• Polymer.dom(parent).querySelector(selector)
• Polymer.dom(parent).querySelectorAll(selector)
• Polymer.dom(parent).childNodes
• Polymer.dom(node).parentNode
• Polymer.dom(contentElement).getDistributedNodes()
• Polymer.dom(node).getDestinationInsertionPoints()

Polymer.domから行う追加や削除といったDOM操作は、パフォーマンスを考慮し遅延して実行するようになっています。そのため、操作後のノードの座標やgetComputedStyle()を使ったスタイルの取得をする場合は、操作をPolymer.dom.flush()を使って適時実行し、反映します。

// 従来のDOM操作
this.appendChild(node);
this.shadowRoot.appendChild(node);

// Polymer.domを使ったDOM操作
Polymer.dom(this).appendChild(node);
Polymer.dom(this.root).appendChild(node);

いずれもDOMのAPIと同じ命名と引数で設計されていますが、サブセットとして用意されているに過ぎず、完全に互換性があるわけではありません。例えば、firstChildといったプロパティは用意されていないので、この場合は代わりにchildNodes[0]を使ってください。

MozillaのWeb Componentsへの関わり方

MozillaもWeb Componentsに対し、積極的な姿勢を見せています。FirefoxでもWeb Componentsの仕様のうち、いくつかが実験的に実装され、またX-TagやBrickといったWeb Componentsをつかったコンポーネント作成を後押しするライブラリもリリースしています。

X-Tag

X-TagはWeb Componentsの作成をサポートするライブラリです。webcomponents.jsをポリフィルとし、記述の簡略化や一元化いったライブラリとしての目的もPolymerと似ている部分がありますが、Polymerに比べて多くのブラウザをサポートしているという特徴があります。X-Tagのブラウザターゲットは以下の通りです。

• Firefox 5+ desktop & mobile
• Chrome 4+, Android 2.1+
• Safari 4+ desktop & mobile
• Internet Explorer 9+
• Opera 11+ desktop & mobile

以下は公式ドキュメント引用のX-Tagを使ったカスタム要素作成のコード例です。Polymerほど多機能ではない分、シンプルで全体像を把握しやすいかもしれません。

xtag.register('x-accordion', {
  // extend existing elements
  extends: 'div',
  lifecycle:{
    created: function(){
      // fired once at the time a component
      // is initially created or parsed
    },
    inserted: function(){
      // fired each time a component
      // is inserted into the DOM
    },
    removed: function(){
      // fired each time an element
      // is removed from DOM
    },
    attributeChanged: function(){
      // fired when attributes are set
    }
  },
  events: {
    'click:delegate(x-toggler)': function(){
      // activate a clicked toggler
    }
  },
  accessors: {
    'togglers': {
      get: function(){
        // return all toggler children
      },
      set: function(value){
        // set the toggler children
      }
    }
  },
  methods: {
    nextToggler: function(){
      // activate the next toggler
    },
    previousToggler: function(){
      // activate the previous toggler
    }
  }
});

Brick

X-Tagだけでなく、UIコンポーネント群として配布しているのがBrickです。PolymerとX-Tagとの関係になぞらえるなら、BrickはCore ElementsやPaper Elementsと同じような存在と言えます。以前まではX-Tagが使われていましたが、現在は非依存になっています。

BrickもPolymerの対抗馬として注目されていましたが、開発が中断されているのか、最近は更新がない状態です。参照しているポリフィルライブラリもwebcomponents.jsではなく、旧称のplatform.jsになっているので、利用する場合は注意してください。

Web Componentsの各仕様へのMozillaの対応

2014年12月の記事ですが、MozillaのWeb Componentsに対する興味深い記事が公開されました。

• Mozilla and Web Components: Update

記事には、端的に述べると 「Custom ElementsとShadow DOMの実装は進め、HTML Importsの実装は見送ります。差し当たって、HTML Importsの機能はJavaScriptのライブラリでやってください。」 とあります。HTML Importsが実装されないことについての議論がコメント欄にて行われていますが、この記事の筆者であるAnne van Kesterenは以下のように述べています。

> Both ES6 modules and service workers open up resource dependency management to web developers. And while ES6 modules is mostly intended for JavaScript, we want to see what kind of dependency systems will be built on these two systems in libraries and frameworks before committing to a standardized design. Especially before committing to one that is not influenced by them. （ES6 modulesやService Workersも依存関係の解決に関わってくる。ES6 modulesはJavaScript向けのものだし、ライブラリやフレームワークにとってどのような機構になるかを見たい）

依存管理の仕組みが、HTML ImportsとES6 modules、Service Workerのような、Web WorkersのimportScriptsといった方法が複数存在してしまうことを懸念してのことと察します。例えばHTML ImportsとES6 modulesは目的を共有するものではないはずですが、HTML ImportsでロードするHTML内でES6 modulesが使われるようなケースも加味して、様子を見たいということでしょう。

Bosonic

BosonicもPolymerやX-Tag同様に、Web Componentsの作成を支援するライブラリです。

• Bosonic Web Component
• bosonic/bosonic – GitHub

PolymerやX-Tagと異なるのは、これらのようにライブラリとして機能を補完したりするのではなく、作成したWeb ComponentsをBosonicを使って事前にビルドするトランスパイラであるという点です。Bosonicでビルドすることで、Internet ExplorerやSafariを含めたWeb Componentsに関するAPIが実装されていないブラウザでも機能するコードが生成されます。

Bosonicはブラウザターゲットは以下の通りです。

• Internet Explorer 9, 10, 11
• Safari 8
• Android 4.4
• iOS 8.1
• Chrome 35
• Firefox 30

Bosonicで生成するコード例

以下は公式で例示されている<b-hello-world>というWeb ComponentsをBosonicを使ってビルドする例です。

<element name="b-hello-world">
  <style>
    :host {
      text-align: center;
      font-weight: bold;
      color: red;
    }
  </style>
  <template>
    <p>Hello world!</p>
  </template>
  <script>
    ({
      createdCallback: function() {
        var root = this.createShadowRoot();
        root.appendChild(this.template.content.cloneNode(true));
      }
    });
  </script>
</element>

Bosonicを使ってコンパイルすると、以下の様なCSSとJavaScriptのコードが出力されます。

b-hello-world {
  text-align: center;
  font-weight: bold;
  color: red;
}

(function () {
  var BHelloWorldPrototype = Object.create(HTMLElement.prototype, {
    createdCallback: {
      enumerable: true,
      value: function () {
        var root = this.createShadowRoot();
        root.appendChild(this.template.content.cloneNode(true));
      }
    }
  });
  window.BHelloWorld = document.registerElement('b-hello-world', { prototype: BHelloWorldPrototype });
  Object.defineProperty(BHelloWorld.prototype, '_super', {
    enumerable: false,
    writable: false,
    configurable: false,
    value: HTMLElement.prototype
  });
  Object.defineProperty(BHelloWorldPrototype, 'template', {
    get: function () {
      var fragment = document.createDocumentFragment();
      var div = fragment.appendChild(document.createElement('div'));
      div.innerHTML = ' <p>Hello world!</p> ';
      while (child = div.firstChild) {
        fragment.insertBefore(child, div);
      }
      fragment.removeChild(div);
      return { content: fragment };
    }
  });
}());

これらのファイルと、いくつかのポリフィル（HTMLImports、MutationObservers、WeakMap、Custom Elements）をHTMLでロードすることで、非対応のブラウザでも<b-hello-world>を使うことができます。

トランスパイラとして導入するメリット

新しいAPIで書かれたコードを、非対応のブラウザ向けに従来のAPIで実行できるようにするというのは、ES6をBabelでES5に変換するというアプローチと同様です。新しい技術の導入は常にブラウザサポートと天秤にかかり、サポートを優先するが故に新しい技術を試すことができないというジレンマも多いでしょう。しかし、こういったトランスパイラによって、新しい技術の導入と古いブラウザのサポートが、コストをかけずに両立できるのは非常に嬉しいところなのではないでしょうか。

<element>タグを使った古い記述であったり、リポジトリの更新もしばらくされていないなど、使うには少々抵抗があります。しかし、トランスパイラというアプローチは非常に興味深いものがありますので、メンテナンスが再開されるのを期待したいところです。

まとめ

Polymer 0.8のアップデート、X-Tag・Brick・Bosonic、およびFirefoxの実装状況について紹介しました。

ブラウザの実装状況は、Internet Explorer・Safariが未だに思わしくありません。仕様についても、FirefoxがHTML Importsの実装を遅らせたようにまだ確実とはいえない状況です。しかしこれは議論が行われている表れでもあり、Polymerの0.8がリリースされたことも含めて、Web Componentsに関する技術は普及に向けて着実に前進しているといえます。

しかし、Shadow DOMによってCSSやJSがカプセル化されても、今度はコンポーネント化のアプローチについて頭を悩ませることになるでしょう。Web Componentsが一般化するには仕様の安定やブラウザのサポートだけではなく、我々開発者でナレッジを蓄積していくことが最も重要です。

本記事は2015年1月に開催されたHTML5 Conferenceでお話させていただいた、 「Beyond CSS Architecture」というCSS設計のセッションをフォローアップする記事です。

本記事では、このセッションの概要と補足、またセッション中に説明できなかった点などについて書いていきます。

※当日のセッションの動画・スライドも公開されているので、文末からご覧ください。

CSSの難しさと、昨今のCSS設計事情

この近年、CSSにおける設計論というのが話題に出てくるようになりました。筆者も拙著『Web制作者のためのCSS設計の教科書』を書いたり、各地でCSS設計をテーマとした講演をする機会が多くありました。

CSSの難しさというのは、石本氏によるCSSコードの評価についての記事にも書かれているのですが、CSSは良くも悪くも厳格なコード規約は少なく、ただ宣言的に書けばいいだけです。セレクタとその詳細度や、後出しされたルールの方が優先されるという、シンプルがゆえに「書く」のは簡単ですが、「直す」のは容易ではありません。

Normalize.cssの作者であり、現在Twitterのエンジニアであるニコラス・ギャラガー氏（@necolas）のツイートを引用するならば、次のように考えられるかどうかです。

Replace "can you build this?" with "can you maintain this without losing your minds?"
— Nicolas Gallagher (@necolas)

複数人のチームでの開発はもちろんですが、自分のひとりの開発であったとしても、いざメンテナンスするとなったときに、数日前に自分が書いたCSSを呪うようなことはよくあります。

中長期的に運用されるWebサイト、Webサービスにおいては、その運用に耐えうるメンテナブルかつ、拡張性のあるCSSを書くことは非常に重要です。 こうしたCSS設計の話題が以前よりも見かけるようになったのは、単純な数ページのWebサイトよりも、少しリッチで複数のテンプレートが必要なWebサイト、Webサービスが増えてきていることもあり、メンテナブルなCSSにするための設計とは何か、というのが求められているからかもしれません。

OOCSSとBEM

セッション内でも取り上げているOOCSSとBEMは、CSS設計を考える上で避けられない方法論のひとつです。

OOCSSは、ページ上で繰り返されるビジュアルパターンをオブジェクトと考え、そのオブジェクトはHTML/CSSまたはJavaScriptのコードの固まりで構成されます。それはボタンやリスト、見出しというような単位であったり、場合によってはただ文字色を赤くするためのものかもしれません。こうした作られた小さなオブジェクトをレゴのように組み合わせてUIを作るというのが、OOCSSの基本的なアプローチです。

BEMは、Yandexという会社のフロントエンド開発チームによって考えられた開発手法です。BEMはUIをBlock,Element,Modifierという分類で設計するのですが、BEMで使われている命名規則とその記法が特徴的で、Blockを名前空間として使うのが良いアイデアとされています。

.menu { ... } /* Block */
.menu__item { ... } /* Block + Element */
.user { ... } /* Block */
.user_login { ... } /* Block + Modifier */
.user__avatar { ... } /* Block + Element */
.user__name { ... } /* Block + Element */

このコード例では.menuがBlockの単位となり、またそれがセレクタの接頭辞にすることで、マークアップ上でつけられたクラス名を見るだけで、どのUI（Block）に依存するものかが分かります。例えばclass="item"だと抽象的すぎて何に依存しているかわかりませんが、.menu__itemであれば分かる、ということです。

また_、__の記号の組み合わせは、設計上のルールとして、単語間がどういう関係性を持つのかを明確にしています。__は一見冗長で、普通に名前をつけるときには使わなそうですが、それが良い意味でただの命名ではなく、デリミタ（区切り）として使われているということです。

このBEMのアプローチの細かなルールは必ずしもオリジナルのBEMに倣っているものばかりではなく、MindBEMdingのような独自のルールで運用されることもあります。筆者のFLOCSSも、いろいろなものを参考にして作成したものです。

モダンなCSS設計の誤解

OOCSS、BEMについて言及される記事を見ると、これらやCSS設計における大きな誤解を招いていると感じることがあります。

OOCSS派か、BEM派か、というような表現も見かけますが、多くの場合、OOCSSは複数のクラスを組み合わせるアプローチ、BEMは単一クラスのアプローチ、というような解釈をされているようです。

OOCSSが体系化された当時にはSassのようなメタ言語もなく、OOCSSを実現するためには複数のクラスを組み合わせるアプローチが適切だったというだけでしょう。事実、彼女自身が“OOCSS and Preprocessors in a tree, K-I-S-S-I-N-G”という講演で、OOCSSとSassを組み合わせたアプローチについて述べています。

また提唱者であるニコール・サリバン氏が関わったプロジェクトにおいては、font-sizeという単位でもオブジェクトとして分解することが、数百と宣言されるfont-sizeプロパティを、たった数個のクラスで管理することに意味がありました。

ただそのいくつかの例が拡大解釈され、.red {color: red;}や.large {font-size: 36px}というような、見た目だけの、コンテンツ派生の意味をもたないクラスを複数組み合わせるアプローチがOOCSSである、と考えられることは少なくありません。

しかし、OOCSSの本質は、現在のHTML/CSSでは難しいモジュラーなアプローチを実践するためのパラダイムである、と筆者は考えています。

一方、BEMについてもいくつかの誤解があるように感じています。Block、ElementあるいはModifierとしての命名と設計は、マークアップを見て、その構造をセレクタにするものではありません。

<nav class="globalNav">
  <ul>
    <li>
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

例えばこのようなマークアップがあった時に、その構造を意識してしまい、次のようなCSSにしてしまうことがあります。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menu__item">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

極端な例ではありますが、近いコードを見ることはあるのではないでしょうか。こうなってしまうと、BEMが冗長すぎる、気持ちが悪い、というのは素直な感情だともいえます。

しかし本来のBEMらしい考え方であれば、このようなマークアップを元にセレクタに命名するものではなく、UIをBlock,Element,Modifierのツリー構造で考え、それが名前にも与えられるものです。

この例でいえば、globalNavをBlockとするならば、それを構成する要素は次のようになるかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu">
    <li class="globalNav__menuItem">
      <a href="/home">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

そもそも、もっと小さな単位にするべきかもしれません。

<nav class="globalNav">
  <ul class="globalNav__menu menu">
    <li class="menu__item">
      <a href="/home" class="menu__target">Home</a>
    </li>
    <!-- more -->
  </ul>
</nav>

どちらが正しいかというものではなく、その時々で適切な命名や分割があるはずですが、少なくともマークアップの構造をなぞって親子関係を命名で表すのが、BEMの命名規則というわけではありません。

最後の例を見ての通り、BEMの記法であっても、複数のBlockとElement、つまりはそれぞれはOOCSS的にいえばオブジェクトであり、組み合わせによって作られるわけです。

つまり、OOCSS派かBEM派かという天秤があるわけではありませんし、思想として良いところを取り入れて、プロジェクトに適切な方法論、設計を考えることが重要です。

逆にいえば、これらは銀の弾丸というわけでもありませんから、OOCSSやBEMがすべての問題を解決するわけでもありません。プロジェクトの規模やその運用の方向性によっては、もっと単純な規約のもとでCSSが書かれていても構いません。

いずれの場合も、そのプロジェクト内において一貫性が保たれていることのほうが大事で、Ideomatic CSSから引用するならば、次のようなことです。

どんなに多くの人が貢献したとしても、どのコードも一人で書いたようにすること。
— Ideomatic CSS

セッションで紹介しているツール、スタイルガイドやStyleStatsのようなツールは、一貫性を保ったCSSを書くための補助となるものです。

これらもまたツールでしかなく、導入しただけで問題が解決するというわけではないので、どのように運用するか、自動化などを含めた仕組みを考えることがより重要です。

まとめ

セッションの最後にWeb Componentsに触れていました。Shadow DOMによって、今のHTML/CSSにないスコープの概念がもたらされれば、現状HTML/CSSをモジュラーに設計・実装するためのいくつかの課題は解決するかもしれません。

しかし、それによってCSS設計が簡単になるか、といえば決してそうではありませんし、どちらかといえばより難しくなるかもしれません。

またWeb Componentsの実用は少し先かもしれませんが、現在でもReactのようなものを採用したプロジェクトにおいては、CSSはどのように設計するか、というのは課題として出てきています。個人的にはそれを考えることは、HTML/CSSをより面白くするものでもあります。（その分の苦しみも多くありますが）

どのような未来がくるにせよ、よりよいCSS設計をするためには、より多くのパターンを知ることだと考えています。

同じリスト型のUIを組むにしても、どのようなパターンが目の前のプロジェクトにおいて適切か、それはパターンを多く知らなければいけません。

そのためには、世の中に多く公開されているフレームワーク、またはプロダクトとして公開されているWebサイトやWebサービスのコードを読むことが大事です。続々と出てくる、新たなOOCSSやBEMのような方法論たちも、食わず嫌いはせず一読してみてください。

CSS設計は非常に難しく、壊れないCSSを書くというのは不可能です。私は次の言葉を胸に、いつもCSSを書いています。

壊れない完璧な設計を求めるのではなく、壊れたときに勇気を持って修復できる設計を
— 斉藤 祐也

はじめから作ることはもちろん、どれだけシミュレーションや設計をしても壊れるときはありますから、それをいかに直しやすいものにするか、そしてそれが他の開発者にとって可能であり、数日後の自分でも直せるようなCSSを書くようにしましょう。

当日のセッションの動画・スライドは、こちらからご覧ください。

Youtube / Slideshare

この記事は、連載「基礎からわかるWeb Components徹底解説～仕様から実装まで理解する〜」の第4回目になります。今回は、前回紹介したGoogleが開発するWeb Componentsのライブラリ、Polymerを元に作られたコンポーネント群「Core Elements」と「Paper Elements」について紹介します。

Core ElementsとPaper Elements

Core ElementsとPaper ElementsはGoogleが開発するWeb Components群です。Core Elementsは、Webを構成する要素をWeb Componentsとして切り出し抽象化したものであり、Paper ElementsはデザインコンセプトMaterial DesignをWebで実現します。

いずれもPolymerをベースに作られている他、各コンポーネントが異なるコンポーネントに依存したつくりになっているものもあります。アーカイブファイルの配布もされていますが、Bowerであればインストール時に依存関係は自動で解決されるため、意識する必要はありません。

インストールして実際に利用する例

Core Elementsのひとつであるcore-imageというコンポーネントを、Bowerを使ってインストールし、実際に使う例を以下に示します。core-imageは通常のimgタグにはない、画像のリサイズやプリロードといった機能を備えたWeb Componentsです。

まず、コマンドラインからBowerを使ってcore-imageをインストールします。bower.jsonに依存情報を記録する場合は--saveオプションを付けます。

$ bower install Polymer/core-image

実行後は、デフォルトであればbower_componentsフォルダ配下にcore-imageと、core-imageが依存するサブリソースがダウンロードされています。core-imageが依存するのはPolymer Coreのみですが、Polymer Coreが依存するリソースがさらに存在するので、それらもダウンロードされています。

ダウンロードしたcore-image.htmlをHTML内でロードすることで、core-image要素を使えるようになります。

<html>
  <head>
    <link rel="import" href="bower_components/core-image/core-image.html">
  </head>
  <body>
    <core-image src="http://lorempixel.com/400/400"></core-image>
  </body>
</html>

サンプルでは、ダウンロードされたPolymer Coreを参照していませんが、ロードしているcore-image.htmlの中でPolymer Coreのインポートが行われているため、改めてPolymer Coreを読み込む必要はありません。

Polymerチームは、依存管理にBowerを使うことを推奨しています。自身でWeb Componentsを作成し、公開する場合は依存するリソースをbower.jsonに書き、コンポーネント内のサブリソースへの参照も、Bowerが使われることを意識するとよいでしょう。

基本的な要素・機能を提供するCore Elements

Core Elementsは、ユーザーインターフェースの基礎です。よく使われるけどブラウザネイティブには提供されていない機能や、Polymerの強力な機能との橋渡しとなるコンポーネントを提供します。後述のPaper Elementsの土台になっているように、拡張前提のコンポーネントも多くあります。

• Polymer core elements Polymer公式サイトのCore Elementsのページ
• Core Elements Sampler Core Elementsのサンプル集

UI関連のCore Elements

UIに関するCore Elementsとしては、既存のHTMLでは提供されていないドロップダウンやオーバーレイといった汎用的なUIや、既存のUIの機能を補完しているコンポーネントが用意されています。

例えば、core-dropdown-menuを使ったドロップダウンが挙げられます。ドロップダウンのUIは今や当たり前のように見かけますが、要件が出る度にイチから実装していたケースも多いのではないでしょうか。

以下は、core-dropdown-menuとcore-menu及びcore-itemを組み合わせて実装するドロップダウンメニューの例（公式サイトから引用）です。

<core-dropdown-menu label="Choose a pastry">
  <core-dropdown class="dropdown">
    <core-selector>
      <core-item label="Croissant"></core-item>
      <core-item label="Donut"></core-item>
      <core-item label="Financier"></core-item>
      <core-item label="Madeleine"></core-item>
    </core-selector>
  </core-dropdown>
</core-dropdown-menu>

他にも以下のようなインターフェースが切り出されています。

• core-collapse 折りたたみコンテンツ
• core-drag-drop ドラッグアンドドロップ
• core-menu メニューアイテム
• core-overlay 他のコンテンツに覆いかぶさるオーバーレイ
• core-tooltip ホバー時に表示されるツールチップ

機能を補完している例としては、core-inputがあります。

core-inputはis="core-input"のように、ネイティブHTMLの拡張として利用します。拡張されたinput要素は、aria-labelやaria-disabledといったARIAで定義されるアクセシビリティを自動で保管したり、フォームとしてサブミットされた時の値をcommittedValueとして取得できるようになります。

他には前述のcore-imageも、後者に該当すると言えるでしょう。

アニメーション関連のCore Elements

Core ElementsにはUIパーツだけでなく、アニメーションを抽象化したコンポーネント群があります。その中核を成すのがcore-animationです。

core-animationでアニメーションを定義し、core-animation-keyframeとcore-animation-propでアニメーションの具体的な挙動を指定します。以下はcore-animation要素でアニメーションを定義する例（公式サイトから引用）です。

<core-animation id="fadeout" duration="500">
  <core-animation-keyframe>
    <core-animation-prop name="opacity" value="1"></core-animation-prop>
  </core-animation-keyframe>
  <core-animation-keyframe>
    <core-animation-prop name="opacity" value="0"></core-animation-prop>
  </core-animation-keyframe>
</core-animation>

<div id="el">Fade me out</div>

<script>
  var animation = document.getElementById('fadeout');
  animation.target = document.getElementById('el');
  animation.play();
</script>

ここではキーフレーム毎に透過度を変化させ、フェードアウトのアニメーションを宣言しています。そして、アニメーションさせたい要素を、core-animationのtarget属性に指定することでフェードアウトさせてます。これはJavaScriptのコードで命令的に行っています。

複数のアニメーションを組み合わせて使いたい場合は、core-animation-groupというグルーピングを担うコンポーネントもあります。

ブラウザAPI関連のCore Elements

提供しているのは、汎用的なアイコンやユーザーインターフェースといったビジュアルに関わる部分に限りません。Core ElementsではAjaxやキーボードアクションのハンドリング等、見た目には直接関わらない機能もWeb Componentsとして抽象化しています。

• core-a11y-keys キー押下のハンドリング
• core-ajax Ajaxの定義及びハンドリング
• core-localstorage ローカルストレージへのアクセス

今まではJavaScriptからそれぞれのAPIを実行し制御していた機能ですが、これらによって、他の要素との連携がPolymerが提供するデータバインディング機能などで容易になる他、HTMLに記述することで宣言的に挙動を定義していくことが可能になります。

以下はデータバインディングを利用してinput要素に入力した値をローカルストレージに保存する例です。

<input type="text" value="{{value}}">
<core-localstorage name="localstorage-key" value="{{value}}"></core-localstorage>

core-localstorageのvalue属性の値がローカルストレージに保存されるので、inputのvalueとバインドすることで入力値がそのまま保存されるようになります。今まではイチからJavaScriptで制御していたことを考えれば、よりわかりやすく、そしてグッと楽になっています。

Material Designを実現するPaper Elements

Paper ElementsはMaterial DesignをWebで実現するWeb Components群です。Polymer Coreへ依存している他、Core Elementsをベースに構成されているコンポーネントが多くを占めています。

Material Designについては、話題のMaterial DesignをWebで実現！Polymerで「Paper Elements」を試そうという記事を一読するとよいでしょう。

• Polymer paper elements Polymer公式サイトのPaper Elementsのページ
• Paper Elements Sampler Paper Elementsのサンプル集

UI関連のPaper Elements

UI関連のPaper Elementsとしては、Core ElementsのUIコンポーネントにMaterial Designを取り入れた要素が多くあります。これは要素の一覧を見比べてもらうとわかるかと思います。

以下はpaper-dropdown-menuの利用例です。

<paper-dropdown-menu label="Your favorite pastry">
  <paper-dropdown class="dropdown">
    <core-menu class="menu">
      <paper-item>Croissant</paper-item>
      <paper-item>Donut</paper-item>
      <paper-item>Financier</paper-item>
      <paper-item>Madeleine</paper-item>
    </core-menu>
  </paper-dropdown>
</paper-dropdown-menu>

このように、利用方法もほぼ同じです。Paper Elementsとして独自に拡張しているのは、影やエフェクトのdurationなどのMaterial Designの表現に関わる部分だけとも捉えられます。

Material Designを体現するエフェクト

影の動きや波紋のようなインタラクションや、奥行きを表現するZ座標のルールといった、特徴的なMaterial Designのコンセプトを担うのは、以下のコンポーネントです。

• paper-ripple クリックした位置から波紋が広がるエフェクト
• paper-spinner 円状のスピナー
• paper-shadow 紙で持ち上げられ影がついたようなエフェクト

特にpaper-rippleとpaper-shadowはMaterial Designのコンセプトの中核を担っており、Paper Elementsのほとんどが、この2つのいずれかに（あるいは両方に）依存したコンポーネントになっています。

paper-shadowを利用する例

実際にpaper-shadowを取り入れてみます。以下はpaper-shadowを使わずにレイアウトしています。

paper-shadowを使うには、冒頭で解説したようにBowerを使ってインストールして、影を付けたい要素をpaper-shadowタグで囲むだけです。

<paper-shadow z="2">
  <core-selector id="theme-selector" selected="default">
    <paper-item name="arta">Arta</paper-item>
    <paper-item name="ascetic">Ascetic</paper-item>
    <paper-item name="color-brewer">Color Brewer</paper-item>
    <paper-item name="docco">Docco</paper-item>
    ...
  </core-selector>
</paper-shadow>

このコードの場合はcore-selectorを囲っていますが、Core Elementsである必要はありません。divでもsectionでも大丈夫です。適用すると以下のようになります。

サンプルページでは、簡単ではありますが他のPaper Elementsも使っています。Paper Elementsを取り入れる例としては、PolymerでMaterial Designなチャットアプリを作ろうという記事に、より実践的なチュートリアルがあります。

Polymer Designer

Core ElementsやPaper Elementsを試す手段としてPolymer Designerがあります。

Polymer Designerではブラウザ上で、Core ElementsやPaper Elementsをドラッグアンドドロップで配置し、データバインディング等もGUI上で行いコンポーネントを作成することが可能なツールです。Web上でお手軽に試したい場合には、こちらを使うのもよいでしょう。

使い方についてはWeb Componentsが変えるWeb開発の未来という記事で触れています。

おわりに

Core ElementsとPaper Elementsの概要・使い方について紹介しました。Web Componentsを使ってWebページの基礎を組み立てるならCore Elementsは便利ですし、Material DesignをWebに取り入れるには、Paper Elementsが既にデファクトスタンダードと言えるかもしれません。

使う分にはもちろん便利なCore ElementsとPaper Elementsですが、興味があればGitHubで公開されているソースコードを見てみることをオススメします。どういった設計でどのように抽象化しているかを見るのも、今後Web Componentsを自分で作っていく上できっと参考になるはずです。

まず始める前にこのライブデモ、Kitteh Anonymousをデスクトップまたはモバイルのモダンブラウザで実際に試してみてください。ここでは、このデモの簡略版であるLiteバージョンを実際に作成する方法をステップ・バイ・ステップで紹介したいと思います。

必要な知識

• Polymerの基礎知識
• パッケージマネージャ、Bowerの基本的な使い方（Polymerと依存するファイルをインストール、アップデートするのに使いますが、必ずしも使う必要はありません）

泉水翔吾さんの記事、Web Componentsを簡単・便利にするライブラリ「Polymer」を使いこなそうや、佐藤歩さんの話題のMaterial DesignをWebで実現！Polymerで「Paper Elements」を試そうを先に読むのをおすすめします。

PolymerとWebスタンダード

ちまたに数多く存在する、JavaScript UI library。Polymerも単にまたそのひとつ、と思うかもしれません。しかしPolymerが他と違うのは、これがW3C WebプラットフォームプリミティブのWeb Componentsを基礎に作られていることです。このWeb Componentsファミリーに含まれるものに

• Shadow DOM
• Custom Elements
• HTML Imports

などが挙げられます。

そしてPolymerに含まれる

webcomponents.js

Object.observe()

レゴブロックのようにWebを構築しよう

Polymer webコンポーネントはカプセル化された何度も再利用できるコンポーネント。まるでレゴで家を構築するかのように、既存のパーツを使ったり自分で組み立てたパーツを使ったりと、いろいろなパーツを組み合わせてWebアプリを作ることができます。

実際にPolymerでアプリを作るには、まず必要な要素をインポートしてから使うことになります。

<!-- Import element --> 
<link rel="import" href="paper-fab"> 
... 
<!-- Use element --> 
<paper-fab icon="send"></paper-fab>

Material DesignとPolymerの関係

Material Designは、既存のどのスクリーンサイズやデバイスにでも対応できる、ビジュアルとインタラクションデザインにすぐれたデザインスペックで、もともとはAndroid 5.0 Lollipop用にデザインされたものが、のちにWeb用としてPolymerのPaper Elementsとして適応されるようにました。

1. Paper Elementsを使ってみよう

さて実際にこれらを使って自分のアプリを作ってみましょう。 まず、Polymerをインストール、そしてアプリ構築に必要なコンポーネントをインポートします。

1.1. Polymerをインストール

$ bower install --save Polymer/polymer

これで必要最低限のファイルがそろいます。

インストールが終わったら、index.htmlの

<head>

webcomponents.min.js

<!DOCTYPE html> 
<html> 
  <head> 
    <script src="bower_components/webcomponentsjs/webcomponents.min.js"></script> 
  </head> 
  <body>
...

1.2. UI コンポーネントをインポート

このデモのUIには、いくつかのPolymer CoreとPaper Elements、そして自作のカスタム要素が使われています。

1. core-scaffold (レスポンシブレイアウトを構成するheader、toolbar、menuなどがすでに揃った骨組み)
2. core-item
3. paper-input
4. paper-fab
5. カスタム (のちに作成しましょう)

Bowerを使って４つのcomponentsをインストールします。

$ bower install Polymer/core-scaffold 
$ bower install Polymer/core-item 
$ bower install Polymer/paper-input 
$ bower install Polymer/paper-fab

インストールが終わったら、これらをHTML importsを使ってインポートします。

<script src="bower_components/webcomponentsjs/webcomponents.min.js"></script>   

<link rel="import" href="bower_components/core-scaffold/core-scaffold.html"> 
<link rel="import" href="bower_components/core-item/core-item.html"> 
<link rel="import" href="bower_components/paper-input/paper-input.html"> 
<link rel="import" href="bower_components/paper-fab/paper-fab.html">

このようにすることで、これらの要素がDOM上で使われる前に依存ファイルを含めて全てがしっかりロードされることになります。

1.3. ベーシックUIの構成

まず、

<core-scaffold>

<core-header-panel>

<core-toolbar>

<core-drawer-panel>

<body fullbleed unresolved>
  <core-scaffold>

    <!-- ドロウアーパネル -->
    <core-header-panel navigation flex>
        <core-toolbar class="tall">
            <!-- an avatar and username will be here -->
        </core-toolbar>
    </core-header-panel>

    <!-- アプリのタイトル -->
    <div tool layout horizontal flex>
        <span flex>Kitteh Anonymous</span>
        <core-icon icon="account-circle"></core-icon>
        <span><!-- number of people online --></span> 
    </div>

    <!-- メインコンテンツ -->
    <div flex>
            ...
    </div>
  </core-scaffold>
</body>

これでアプリのコア・ストラクチャーができました。

<core-scaffold>

ここで

<body>

fullbreed

unresolved

他、要素の要所に

flex

layout horizontal | vertical

1.4. 個々のUI Elementsを使う

次に、このベースレイアウトの中に、先ほど一緒にインポートした個々のUIパーツを使います。 例えば次に示すコードサンプルでは、スクリーン横幅にあわせスタイライズされたインプットと、送信ボタンを表示しています。

二重カーリーブラケットに囲まれた

{{input}}

{{sendMyMessage}}

on-

<!-- メインコンテンツ -->   
<div class="send-message" layout horizontal>
 <paper-input flex label="Type message..." id="input" value="{{input}}"></paper-input>
 <paper-fab icon="send" id="sendButton" on-tap="{{sendMyMessage}}"></paper-fab> 
</div>

実際のアプリの中でコンポーネントがどのようにインポートされているかは、GitHub Repo上のlite.htmlのソースコードを見て確認してみてください。

1.5. データバインディング

PolymerはHTMLの新スタンダードである

<template>

<template>

<body fullbleed unresolved>
  <template is="auto-binding">
    <core-scaffold>
      ...
    </core-scaffold>
  </template>
</body>

これで、前チャプター(1.4)で既出の

paper-input

{{input}}

var template = document.querySelector('template[is=auto-binding]');
doSomething(template.input);

他、このデータモデルを使えば、要素を繰り返し使うようなマークアップを簡略化するなどということもできるのです。 実際にドロウアーパネルUIの中に、

core-item

<template repeat="{{item in items}}">
  <core-item icon="{{item.icon}}" label="{{item.title}}"></core-item>
</template>

core-item

<core-icons>

template.items = [
  {title: 'Uno', icon: 'cloud'},
  {title: 'Dos', icon: 'polymer'},
  {title: 'Tres', icon: 'favorite'}
];

これで、モデルを生成・変更した時に自動的にテンプレートにインスタンスが生成され、DOM上には下の図のように表示されます。

2. カスタム要素の作成

メインUIとなる部分にチャットの会話を表示させましょう。このUIパーツには、アバター、ユーザーID、チャットのテキストが表示させるようにしたいのですが、Polymer CoreにもPaperにもそういったバーツは存在しません。ですので自分でカスタム要素を作ってみましょう。

まず新規のHTMLファイルを作成します。ここではこのファイル名を、

x-chat-list.html

このカスタム要素は、属性、

avatar

color

username

text

ここでは、カスタム要素の作製法を一から説明はしませんが、簡略化されたカスタム要素は次のようになります。

<polymer-element name="x-chat-list" attributes="avatar color username text">
  <template>
  <section class="user-list" layout horizontal>
    <div class="avatar {{color}}" style="background-image: url({{avatar}})"></div>
    <div flex>
      <div class="username">{{username}}</div>
      <div class="text">{{text}}</div>
    </div>
  </section>
  </template>
  <script>
    Polymer('x-chat-list', { // デフォルト値を指定
      avatar: '', 
      color: '',
      username: '',
      text: ''
    });
  </script>
</polymer-element>

この例ではわかりやすく見せるために、

<style>...</style>

x-chat-list.html

できあがったら

index.html

<link rel="import" href="x-chat-list.html">

<div flex class="chat-list">
  <template repeat="{{message in messages}}">
    <x-chat-list color="{{message.color}}" 
                 avatar="{{message.avatar}}" 
                 username="{{message.uuid}}" 
                 text="{{message.text}}"></x-chat-list>
  </template>
</div>

データは実際の生のチャットの会話を、PubNubデータ・ストリームサービスを使って表示させます。詳しくは次のセクションで説明します。

かなりはしょってしまいましたが、カスタム要素を作る詳しい説明は公式のドキュメントを参照してください。

3.PubNub Elementでメッセージの送信・受信をする

アプリのUI部分はすべて完成しましたので、今度はチャットルームそのものを作ってみましょう。データの送受信はPubNubが提供するリアルタイム・データストリームのPolymerエレメント版である、

<pubnub-element>

<pubnub-element>

publish_key

publish_key

3.1. <pubnub-element>をインストール・インポート

インストールは、他の要素同様にBowerを使うことができます。

$ bower install --save pubnub-polymer

インストール後は

index.html

<link rel="import" href="bower_components/pubnub-polymer/pubnub-element.html">

3.2. <pubnub-element>を使う

まず、

<core-pubnub>

<core-pubnub publish_key="your_pub_key" subscribe_key="your_sub_key" uuid="{{uuid}}">
</core-pubnub>

ここで使われる

uuid

var randomColor = function() {   
  var colors = ['navy', 'slate', 'olive',...];   
  return colors[(Math.random() * colors.length) >>> 0];
};

var randomCat = function() { ... }; 

template.uuid = randomColor() + '-' + randomCat();

3.3. メッセージの送信

<core-pubnub-publish>

<core-pubnub publish_key="demo" subscribe_key="demo">
  <core-pubnub-publish id="pub" channel="polymer-chat" message="Hello">
  </core-pubnub-publish>
</core-pubnub>

では、ユーザが文字を入力して送信ボタン(

<paper-fab>

on-*

on-tap

<paper-fab>

<paper-fab icon="send" on-tap="{{sendMyMessage}}"></paper-fab>

template.sendMyMessage = function(e) {
  if(!template.input) return; // 入力フィールドが空の場合は何もしない

  template.$.pub.message = {
    uuid: uuid, 
    avatar: avatarUrl,
    color: color, 
    text: template.input  
  };
  template.$.pub.publish();
};

これでユーザの情報とメッセージテキストが、サーバに送られました。次はすべてのユーザがこれを受信して、内容ををDOMに表示させてみましょう。

3.4. 受信データのリアルタイムバインディング

ネットワークに送られたメッセージは

<core-pubnub-subscribe>

<core-pubnub-subscribe 
  channel="polymer-chat" 
  id="sub" 
  messages="{{messages}}" 
  on-callback="{{subscribeCallback}}">

ここでの

messages

<x-chat-list>

messages

messages="{{messages}}"

core-pubnub-subscribe>

<x-chat-list>

ではもう一度、

<x-chatlist>

<div flex class="chat-list">
  <template repeat="{{message in messages}}">
    <x-chat-list 
      color="{{message.color}}" 
      avatar="{{message.avatar}}" 
      username="{{message.uuid}}" 
      text="{{message.text}}"></x-chat-list>
  </template>
</div>

メッセージが受信された際には、

<core-pubnub-subscribe>

on-callback

template.subscribeCallback = function(e) {
  template.async(function(){
    var chatDiv = document.querySelector('.chat-list');
    chatDiv.scrollTop = chatDiv.scrollHeight; // scroll to bottom
  });
};

これで、PolymerでMaterial Designの美しいデザインを使った簡単なチャットルームが完成しました！

このチュートリアルではわかりやすくするために、デモで使われているすべてのフィーチャーについてや、Shadow DOMのスタイリングについての説明は省略してあるので、さらに知りたい方は是非、GitHub のRepoで確認してみてください。

デモとチュートリアル、楽しんでいただけたなら幸いです！Happy coding!

年間読まれた記事ランキングTOP20！

＜1位＞
Googleはなぜモバイルに力を入れるのか？これからのWebパフォーマンスで注力すべきポイント
── 川田寛

＜2位＞
モバイルWeb開発に役立つ！Chrome DevToolsの新機能「デバイスモード」
── Tomomi Imura

＜3位＞
Googleのベストプラクティスに沿ったモダンな製作の出発点「Web Starter Kit」
── 中島 直博

＜4位＞
Web Componentsが変えるWeb開発の未来
── 泉水翔吾

＜5位＞
HTML5とかモバイルとかJSフレームワークとか、ぶっちゃけどうなの座談会
── 村地彰

＜6位＞
初心者でも絶対わかる、WebGLプログラミング＜three.js最初の一歩＞
── 小山田 晃浩

＜7位＞
いまや最も優れたJavaScriptフレームワーク「AngularJSリファレンス」出版記念会
── 佐川 夫美雄

＜8位＞
HTML5で実現できる！環境光に合わせたレスポンシブなUI
── Tomomi Imura

＜9位＞
いま、UXを語るのはなぜ悩ましいのか？─長谷川恭久ロングインタビュー
── 白石 俊平

＜10位＞
エンタープライズで使える！実践から学ぶJavaScript MVCフレームワークの選び方
── 酒巻瑞穂

＜11位＞
Web技術者も知るべきデモ・プレゼンの極意（西脇資哲氏）「Microsoft de:code」イベントレポート
── 岩瀬 義昌

＜12位＞
HTML5が変える、エンタープライズITの可能性とこれから
── 川田寛

＜13位＞
【速報】Google I/O 2014 キーノート ライブレポート
── 岩瀬 義昌

＜14位＞
自分の書いたコードが即座に解析できる「StyleStats」でCSSを測ろう！
── 石本 光司

＜15位＞
キミはionicを知っているか？AngularJS+PhoneGap+美麗コンポーネント群！
── 金井 健一

＜16位＞
話題のMaterial DesignをWebで実現！Polymerで「Paper Elements」を試そう
── 佐藤歩

＜17位＞
HTML5ハイブリッドアプリ開発、最新動向はやわかり！
── 久保田 光則

＜18位＞
ミツエーリンクスのCTOに「UXとWebアクセシビリティ」について聞いてきた─木達一仁ロングインタビュー
── 白石 俊平

＜19位＞
Web Componentsを構成する4つの仕様 ー Web Components基礎編
── 泉水翔吾

＜20位＞
NUCで手のひらサイズの格安WebSocketサーバーを立ててみた(ハード組立編)
── 高橋 登史朗

モバイルWeb、WebComponets、AngularJS…

モバイルWebというキーワードは今年注目を集めましたね。関連記事がいくつかランクインしています。また、WebComponets、AngularJSという今年話題になった技術の記事もランクインしています。特集では、GoogleI/O特集やExperts Opinions「UX」特集が注目を集めました。UX特集は年明けにも記事公開を予定していますので、お楽しみに！

HTML5 Experts.jpは2014年も多くの方々にご愛読いただきまして、執筆陣・編集部共々感謝しています。ありがとうございました。来年も引き続き宜しくお願いいたします。