はじめに
インターネットの世界でWebページからWebアプリケーションへの置き換えが進むに伴い、そうしたサイトに新しい機能を追加するためのさまざまな取り組みが行われています。その中で、アプリケーションで最も多く利用されていると思われるのは、Webページのさまざまな部分をスクリプトとユーザーイベントによってプログラム的に制御する方法でしょう。多くの場合、このプロセスでは要素に対する何らかのバインディングを後で作成します。そのため、長いスクリプトのブロックと、JavaScript関数を呼び出すインラインイベントハンドラがいくつも必要になり、かなりごたごたしたJavaScriptコードになることも珍しくありません。
アプリケーションの簡素化や再利用性の向上を考えるならば、別の方法を検討してみてはどうでしょうか。この方法の背後にある考え方は、一見するとごく単純です。開発者はWebページのCSSページ内で「振る舞い（behavior）」と呼ばれるスクリプトを定義します。このスクリプトは、XMLとJavaScriptの組み合わせによるXML Binding Language（XBL）で記述された「振る舞い言語ドキュメント」にバインドされます。ページがロードされると、所定のルールによって関連付けられた要素が振る舞いを獲得し、独自の外見、ユーザー入力に対する独自の応答、および基になる独自のデータを持つ新しい「要素」として実質的に機能するようになります。
XBLは、2000年代の初めからさまざまな形で具体化されてきました。Microsoftは1990年代後期にビヘイビア（behaviors）と呼ばれる一種のバインディングを生み出しましたが、この技術が他のブラウザに普及することはありませんでした。2003年初めに、XML User-interface Language（XUL）を使って拡張機能を作成する1つの手段として、FirefoxにXBLが導入されました。しかしFirefox以外では、XBLは正式に標準として規定されませんでした。XBLバインディングは、Firefoxの登場とほぼ同時期からFirefoxのWebページで機能してきましたが、やはり他のベンダーが追随することはありませんでした。
2006年に、GoogleのIan Hickson氏がW3C Web Application Formats Working Groupの一環として、XBL 2.0仕様の最初のバージョンを公開しました。この仕様はMozilla XBL 1.0言語に一部基づいていますが、Firefoxの実装で問題を起こしがちな設計上のさまざまな問題を修正することを目指しています。XBL 2.0は2007年3月16日から勧告候補（Candidate Recommendation）になっていますが、XBL 2の要件である2つの正式な実装の提示が待たれています。草案が（通常は最終的な意見を募る短期間の「勧告案（Proposed）」の段階を経て）正式な勧告になるには、これらの実装が必須の前提条件と見なされています。
Mozillaは2008年に、4.0リリースでXBL 2の実装を目指すことを発表しました。この作業は現在進行中であり、正式な勧告候補になってから基本機能が変更される可能性はほとんどないことから、彼らの目標が実現する可能性は極めて高いと考えられます。
一方のGoogleは、最近SVG Webプロジェクトで用いた手法と同じような代替路線を歩んでいます。他のブラウザベンダーがXBL 2を採用するのを待つ代わりに、Googleでは最近、どのブラウザでも動作するように設計されたコードを携えて、JavaScriptベースのXBL 2コードプロジェクト（http://code.google.com/p/xbl/）を設立しました。現時点で、過去4年以内に作成された主要なブラウザはすべてサポートされています。スクリプトを記述する必要性がすべて軽減されるわけではありませんが、ドキュメントのヘッダーに次のスクリプト要素を1つ追加するだけでWebページ内にコードを実装できます。
[xml]<script type="text/java-script" src="xbl.js"></script>[/xml]
このスクリプト要素を追加すると、ブラウザの種類にかかわらず、CSSスタイルシート内で定義された振る舞いが呼び出されます。さらに、xbl.jsライブラリ（上記のプロジェクトサイトから入手可能）はライブラリを呼び出す前にチェックを実行し、XBL 2のサポートがネイティブで有効になっているかどうかも確認します。有効になっている場合、コードはそのプラットフォームにネイティブな（おそらくブラウザに最適化された）XBLライブラリに処理を任せます。
Twitter XBL要素の宣言
以前に私がこのサイトで行ったことを踏まえて、Twitterのフィードを取得し、最新のメッセージをWebサイト内のユーザーの「フレンド」チャンネルに表示する仕組みを構築してみます。これは純粋なクライアントソリューションではありません。Twitterと通信する最初のWebページを表示し、JSONストリームをクライアントに送り返すサーバ上にプロキシがあることが前提となります。ただし、この情報の表示と更新は XBLコンポーネントによって処理されます。
XBLを使った標準的なWebページは、大抵驚くほど簡潔で単純明快に見えます。例えば、Twitterアプリケーションの場合、コードは次のようになります。
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Twitter Test</title>
<script type="application/java-script" src="../lib/xbl2/xbl.js"/>
<style type="text/css"><![CDATA[
twitter {binding:url('twitter.xml#twitter');width:400px;height:500px;}
]]></style>
</head>
<body>
<h1>Twitter Test</h1>
<p>This is a Twitter Test.</p>
<table>
<tr>
<td>
<twitter frame="myframe"/>
</td>
<td>
<iframe id="myframe" name="myframe" src="" width="600" height="500"/>
</td>
</tr>
</table>
</body>
</html>
おそらくここで最も注目すべき点は、XBLライブラリのバインディング自体を除いて、明白なJavaScriptコードがほぼ存在しないことでしょう。コンポーネントは単にタグとして指定され、次のようにCSS宣言で識別されています。
<style type="text/css"><![CDATA[
twitter {binding:url('twitter.xml#twitter');width:400px;height:500px;}
]]></style>
twitter.xmlは、XBLが含まれるファイルの名前です。#twitterは、ファイル内でその特定のID属性を持つXBL [xml]binding[/xml]を示します。
この手法の1つの効果は、関心が明確に分離され、それに対応してコードが簡潔になることです。コードの混ざった複雑で未分化のHTMLが不要になり、HTMLコンテンツをはるかに単純で分かりやすくできます。ここからさらに、単純にXBL拡張として定義（場合によっては再定義）されるナビゲーション要素、ヘッダーおよびフッター要素といった考え方が生まれます。
この例では、Twitterアカウントのユーザー名とパスワードの入力ボックス、コンテンツ送信用のボタン、および最新のツイート（つぶやき）を表示するペインからなるアプリケーションを組み込んでいます。30秒おきに、アプリケーションは自動更新を実行します（Twitter.comでは自動更新の頻度を1時間あたり150回に制限しているので、30秒間隔（1時間あたり120回）の更新はこの枠内に収まります）。
さらに、この要素にはframeという名前の（オプションの）属性も含まれています。ページ内にiframeまたはHTMLフレームがあり、そのフレームの@nameを要素の@frame属性に指定している場合は、ユーザーがツイートペインのリンクをクリックすると、そのリンクがフレーム内に表示されます（図1）。それ以外の場合は、リンクをクリックすると、ユーザーの設定に応じてブラウザの新しいタブまたはウィンドウが開きます。
