レベル: 初級 Edd Dumbill (edd@xml.com), Editor and publisher, xmlhack.com
2006年 1月 25日 2つのパートからなるこのシリーズでは、今後のHTMLに関してWeb制作者、ブラウザー開発者や標準化団体が提案しているさまざまな方法をEdd Dumbillが論じます。このシリーズでは、WHATWG仕様で実現される漸進的なアプローチと、W3Cにより提案された急進的なXHTMLのクリーンアップについて扱います。さらに、W3Cの新たなRich Client Activityについても概要を述べます。このパート2では、Eddは、将来のWebマークアップを指定するためにW3Cで進められている作業に重点を置いて説明します。
このシリーズの前回の記事では、過去の問題点を修正するためにも、Webページおよびアプリケーションに求められているタスクの要求の高まりを満たすためにも、HTMLのアップデートが必要であることを述べました。ブラウザー・ベンダーのゆるやかな連携であるWHATWG（Web Hypertext Application Technology Working Group）が進めているWeb Applications 1.0およびWeb Forms 2.0仕様の策定作業を説明しました。
この記事では、W3C（World Wide Web Consortium）による次世代のXHTML仕様の策定と、Ajaxアプリケーションによって例示されたような「リッチ・クライアント」動作に対する要求への対応について述べます。
W3Cには以下の4つのワーキング・グループがあり、それぞれが非常に興味深い仕様を策定しています。
- HTML（現在はXHTML）
- XForms
- Web APIs
- Web Application Formats
「参考文献」に、それぞれへのリンクがあります。この記事では主にHTMLワーキング・グループの作業に重点を置いて説明しますが、Webの将来の方向性を探る意味でも、他のワーキング・グループの作業に触れておきましょう。
XForms
XFormsは、現在のHTMLフォームに取って代わるW3Cの仕様です。より豊富な機能を持ち、結果をXML文書として処理アプリケーションに渡すように設計されています。XFormsはモジュール方式なので、XMLに付加するだけでなく、どんなコンテキストでも使用できます。XFormsとHTMLフォームの主な違いは、次のとおりです。
- XFormsは、ユーザー・インターフェースのプレゼンテーションをデータ・モデルの定義から切り離します。
- XFormsでは、XML文書の作成と利用が可能です。
- XFormsは、デバイスに依存しません。たとえば、音声ブラウザーとデスクトップ・ブラウザーで同じフォームを使用することができます。
- XFormsでは、送信前に入力の検証と制約が可能です。
- XFormsでは、スクリプティングを必要とせずに、多段階フォームが可能です。
モジュール化言語なので、XHTML 2.0はXFormsをフォーム機能モジュールとしてインポートします。
Web APIs
W3CのWeb APIsワーキング・グループは、クライアント・サイドのWebアプリケーション開発用の標準APIの仕様の策定を担当しています。このうち、最初の、そして最もなじみのあるものは、（WHATWGが記述しているテクノロジーでもある）Ajaxの中核をなすXMLHttpRequest機能です。プログラマーは、ECMAScriptなど、ブラウザー環境でサポートされている任意の言語から、これらのAPIを使用することができます。
仕様策定中のその他のAPIには、次のようなものがあります。
- ブラウザーのWindowオブジェクトを扱うためのAPI
- DOM Level 3 EventsおよびXPath仕様
- 時限イベント用のAPI
- XMPPやSIPなど、非HTTPネットワーキング用のAPI
- クライアント側の持続ストレージ用のAPI
- ドラッグ・アンド・ドロップ用のAPI
- ダウンロード監視用のAPI
- ファイル・アップロード用のAPI
これらのAPIはXHTML 2.0と並行して実装されるとは限りませんが、4年後のブラウザーは、この両方を統合して、Webアプリケーションのためのリッチなプラットフォームを提供することになるでしょう。
Web Application Formats
XHTML 2.0は、Webアプリケーションのユーザー・インターフェースに問題がありますが、それがすべてではありません。MozillaのXULやMicrosoftのXAMLなどのテクノロジーは、ユーザー・インターフェース用のリッチなXMLボキャブラリーを目指しています。
Web Application Formatsワーキング・グループは、XULやXAMLでユーザー・インターフェースを指定するための宣言フォーマットの開発と、カスタム・マークアップと既存テクノロジーを結びつける宣言言語XBL2の開発を担当しています。XBL2は、基本的に、プログラマーにとって、Webアプリケーション用の新しいウィジェットを書く手段となります。
なぜXHTML 2.0か
XHTML 1.0の目的は、HTMLからXMLボキャブラリーへの移行でした。これにより、大文字と小文字の区別、強制的に引用される属性値、開始タグと終了タグの対など、XML構文の制約がHTMLに導入されました。その上で、XHTML 2.0は、Webページをマークアップする言語としてのHTMLの問題の解消を目指しています。
W3CのSteven Pembertonは、アムステルダムで開催されたXTech 2005カンファレンス（「参考文献」を参照）でのプレゼンテーションの中で、XHTML 2.0の設計目標を次のように述べています。
-
できるだけXMLを使用する：XMLにすでにある言語機能については、重複や作り直しを避ける。
-
プレゼンテーションの構造化：CSSスタイルシートのおかげで、HTMLで明示的にプレゼンテーション・タグを使用する必要がなくなった。
-
HTMLを書きやすくする：HTMLの不要な特異性をなくす。
-
アクセシビリティと装置独立性の強化：文書の読み取り方法についての前提条件をできるだけ少なくする。
-
多言語対応の強化。
-
より良いフォーム：長い間待ち望まれていた改良が必要。
-
スクリプティングの必要性をなくす：典型的なスクリプティングの用例をHTMLそのものに含める。
-
より良いセマンティクス：HTMLとセマンティックなWebアプリケーションとの統合を容易にする。
これらの目的は、確かに、HTMLを少しでも使ったことがある人にとっては賞賛に値するように思えます。これらがXHTML 2.0でどのように達成されたか、もう少し詳しく見ていくことにしましょう。
セクションとパラグラフ
もうずいぶん前のことになりますが、私がHTML初心者だったときには、この言語のテキスト構文要素にかなり困惑させられました。なぜ6種類もの見出しレベルがあり、それぞれどんなときに使えばよいのか。また、見出しが示しているセクションが見出しに含まれないのはなぜか。XHTML 2.0は、新しい<section>および<h>（heading：見出し）要素によって、これに答えています。
<section>
<h>Level 1 heading</h>
...
<section>
<h>Level 2 heading</h>
...
</section>
</section>
|
これはXHTML 1.0よりかなり論理的な配置であり、他の多くのマークアップ・ボキャブラリーのユーザーにとって親しみやすいことでしょう。プログラマーにとって大きなメリットは、見出しレベルのナンバリングをし直さなくても、数セクションのコンテンツを文書に含められることです。
そして、これらの見出しにCSSスタイリングを使用することができます。ブラウザーによるXHTML 2.0のデフォルトの実装として、これらのいくつかが事前定義されることになると予想されますが、明示的に書くとすれば、次のようになります（XHTML 2.0仕様からの抜粋）。
h {font-family: sans-serif; font-weight: bold; font-size: 200%}
section h {font-size: 150%} /* A second-level heading */
section section h {font-size: 120%} /* A third-level heading */
|
XHTML 1.0のもうひとつの論理面の変則性は、リストを使用するためにはパラグラフを閉じなければならないことです。実際、どんなブロック・レベル要素（ブロッククォート、フォーマット済みセクション、テーブルなど）を使う場合も、パラグラフを閉じなければなりません。このようなコンテンツを同じパラグラフの流れの一部として正しく使えるときに、こうしなければならないというのは、非論理的です。XHTML 2.0では、この制限がなくなりました。できないのは、パラグラフを別のパラグラフの中に入れることだけです。
イメージ
HTMLの<img>タグは、実際には、あまり柔軟性がありません。Pembertonが指摘したように、代用メカニズムはaltテキストしかなく（新しい画像形式の採用を妨げています）、altテキストをマークアップすることはできず、また、longdesc属性は使いづらいため、ほとんど使われていません。（longdescは、alt属性で表示されるよりも詳しい画像の説明があるURIを示すために使用されます。）
XHTML 2.0では、この問題に対するお見事な解決策が導入されました。すなわち、どんな要素にもsrc属性を指定できるようになりました。これによりブラウザーは、要素の内容をURIの内容で置き換えます。単純な例では、これは画像です。しかし、ブラウザーが表示できるものであれば、SVGでも、XHTMLでも、その他のコンテンツ・タイプでもかまいません。
<img>タグそのものは残されていますが、その中にコンテンツを含めることができるようになりました。src属性の新しい運用は、次のマークアップ例のように、altテキストが要素の内容となることを意味します。
<p><img src="http://example.com/water.png">H<sub>2</sub>O</img></p>
|
これは日本語などの言語にとって特にうれしいニュースです。日本語でルビ（「参考文献」を参照）を付けるには、インライン・マークアップが必要ですが、今までの属性値では不可能でした。
XHTML 2.0は、<object>要素で、より一般的な画像包含形式を提供しています。この要素を使用すると、静止画や動画からFlashまたはJavaテクノロジーのような実行可能コードまで、どんな種類のオブジェクトでも含めることができます。これにより、ブラウザーの能力に応じて画質低下を手際よく処理するテクニックが可能になります。それぞれの内側に複数の<object>要素を埋め込むことができます。たとえば、一番外側にFlashムービーを置き、その内側にAVIビデオ・ファイルを置き、その内側に静止画を置き、そして最後に、ネストされたオブジェクトの中心にテキストを置くことができます。詳しくは、XHTML Object Module（「参考文献」にリンクがあります）を参照してください。
拡張可能なセマンティクス
HTMLではずいぶん前から、<address>と<title>など、意味的に関連のある要素がいくつかありました。これらで問題なのは、このような要素は数が少なく、拡張できないことです。一方、class属性を使用して、HTML要素にセマンティクスを与えようという試みもありました。これは、classの目的を当初の設計目的より広げようとするものであり、この属性はもっぱらCSSスタイリングの適用に使用されているため、あまり手際よく適用することはできません。（classの目的については異論があるかもしれませんが、後者については否定しようがありません。）
このようなその場しのぎの方法ではなく、XHTML 2.0では、文書内でRDFと同様のメタデータを指定する方法が導入されています。RDFステートメントは、主語、プロパティー、目的語の3つの部分（トリプル）から成ります。たとえば、英語では、「my car」、「is painted」、「red」というトリプルです。
about属性はrdf:aboutと同様の役目を果たし、RDFトリプルの主語を指定します。これは省略が可能で、省略された場合は、文書そのものが主語となります。property属性は、参照されるプロパティーのURIです（プレフィックスを適切に宣言することで、名前空間の省略形を使用できます。詳しくは、「参考文献」の「XHTML 2.0 Metainformation Attributes Module」を参照してください）。
最後に、トリプルの3番目の値は、aboutおよびproperty属性が適用される要素の内容、または、それが空の場合は、content属性の値によって与えられます。以下は、HTMLの<meta>タグの既存の用例から容易に類推できる単純な用例であり、ページ・ヘッダーで作成者を指定しています。
<html xmlns="http://www.w3.org/2002/06/xhtml2/" xml:lang="en">
<head>
<title>Edd Dumbill's Home Page</title>
<meta property="dc:creator">Edd Dumbill</meta>
</head>
...
</html>
|
今度は、Pembertonが挙げた例を見てください。これは、文書の実際の本文でのメタデータの使い方を示しています。
<h property="title">Welcome to my home page</h>
|
これは、見出しを文書のXHTML 2.0タイトルとして示し、インライン見出しとして指定しています。最後に、すべての文書でタイトルを2回書くことになります。
GRDDL（Gleaning Resource Description from Dialets of Language、「参考文献」を参照）というシンプルな変換テクノロジーのおかげで、XHTML 2.0文書からRDFメタデータを抽出する単一の標準ができました。
XHTML 2.0には、他にも多くの変更点がありますが、その多くは、XFormsなどの仕様の並行開発に関連しています。そのすべてについて説明する余裕はありませんが、XHTML 1.0から大きく前進したことは確かです。
XHTML 2.0でのその他の新しいおもちゃ
<pre><code>...</code></pre>と書くことにうんざりしていませんか？ 新しい<blockcode>要素を使えるようになりました。
アクセシビリティ要件を満たす一助として、XHTML 2.0では、どの本文要素でも指定できるrole属性ができました。たとえば、ページ内の純粋なナビゲーション要素にrole="navigation"と指定すると、読み上げエンジンによってインテリジェントに処理されます。
今のところ、ブラウザーは、Tabキーによるフォーカスの移動をある程度サポートしていますが、かなり恣意的です。新しいnextfocusおよびprevfocus属性によって、フォーカスが画面要素間を移動する順序を制御することができます。これは、ナビゲーション可能なユーザー・インターフェースの作成にとって、きわめて重要な機能となります。
XHTML 2.0に備える
高度な機能における変更点は多いものの、XHTML 2.0がHTMLであることに変わりはありません。新しい要素が追加されましたが、XHTML 2.0の大部分は、そのまま機能します。<h1>から<h6>までの要素は、<img>と同様、互換性を保つためにそのまま引き継がれました。
ただし、XHTML 2.0の使命は、構文として厳格な後方互換性を維持することではないので、現在のブラウザーのHTMLレンダラーでは、XHTML 2.0文書の豊かな表現力を処理することはできません。それにもかかわらず、現在のほとんどのWebブラウザーは、任意のXMLプラスCSSをうまく表示しており、XHTML 2.0の大部分も同じように表示できます。セマンティック面での機能強化を享受することはできないとしても。
XHTML 2.0での違いの中には、非常に重要なものもあります。最も注目すべきはXFormsへの移行であり、HTMLの非XML的な遺産からの完全な脱却です。したがって、今すぐあなたのサイトをXHTML 2.0対応に切り替えることはできませんが、将来のための準備を始めることはできます。
- CSSの使用を真剣に考慮し、プレゼンテーション・マークアップをすべて取り除くように努力してください。
- どのようにすれば、あなたのページにマイクロフォーマットを導入できるか考えてください。マイクロフォーマットでは、既存の標準を使用して、HTMLでメタデータを表現することができます（「参考文献」を参照）。
- まだ始めていない場合は、XHTML 1.0を使ってみてください。今の時点で、XHTML 1.0ページを通常のHTMLと同様に表示させるのは、XHTML 1.0 HTML互換性ガイドラインに従って作られていれば可能ですが、厄介な問題が起きることもあります。XHTML 2.0をこのように表示することはできません。詳しくは、「参考文献」を参照してください。
- X-Smilesブラウザー（「参考文献」を参照）を使ってみてください。これは、XHTML 2.0だけでなく、SVG、XForms、およびSMIL 2.0 Basicの機能をサポートしています。
- XHTML機能に基づく新しいクライアント・システムを作成する場合は、XHTML 2.0を出発点とすることを真剣に考慮してください。
最後に、XHTML 2.0は仕様として最終的に確定されていないことに注意してください。この記事の執筆時点で、まだW3Cのワーキング・ドラフト段階であり、これは、勧告になるまでにいくつかの過程を経ることを意味します。重要なのは、勧告候補段階を経なければならないことです。この段階で、実装経験が収集されます。
W3C HTMLワーキング・グループ・ロードマップによると、XHTML 2.0は2007年まではW3C勧告にならないでしょう。つまり、2006年は、重要な導入経験を得るための年になるということです。
W3C XHTML 2.0とWHATWG HTML 5の比較
この2つの記事では、WHATWGのHTML 5とW3CのXHTML 2.0の両方について顕著な点を説明しました。この2つのイニシアチブは、まったくの別物です。草の根組織であるWHATWGが目指しているのは、HTML 4とXHTML 1.0の、ゆっくりとした段階的強化であり、一方、企業の支援を受けているXHTML 2.0は、HTML言語の包括的なリファクタリングです。
このような違いはありますが、この2つのアプローチは互換性がないわけではありません。WHATWG仕様の成果のうち、手軽に利用できるもののいくつかは、すでにブラウザーに実装されていますし、HTMLの事実上の拡張を記述したことは、WHATWGの功績のひとつです。この中でも、XMLHttpRequestなど、重要な部分については、W3CのRich Client Activity仕様に採用されるでしょう。WHATWGは、Web標準の世界の有用な触媒の役目も果たしています。
さらに言えば、XHTML 2.0アプローチは、XML、CSS、およびECMAScriptのモジュール方式の処理が急速に定着しつつあるWebにとって、クリーンアップされたボキャブラリーを提供します。電話やデジタルTVなどの組み込みデバイスは、煩雑なHTMLというWebの遺産をサポートする必要がなく、純粋なXMLボキャブラリーとしてのXHTML 2.0のメリットを自由に活用することができます。さらに、アクセシビリティと多言語対応のための新しい機能により、XHTML 2.0は、ユニバーサルと言える初めてのXML文書ボキャブラリーであり、マークアップに基づく多くの試みにとって、健全かつ経済的な出発点となっています。
これまでと同様、HTMLの未来は変化に富み、ときには混乱もあるかもしれませんが、XHTML 2.0が最終的には広く受け入れられ、採用されることでしょう。Web上の唯一のXMLボキャブラリーだとしたら問題だったかもしれませんが、ブラウザーがSVG、XForms、その他のテクノロジーを扱えるようになってきた今、XHTML 2.0は、それらと同様、もうひとつのXMLベース・ボキャブラリーにすぎないように見えてきました。
参考文献 学ぶために
製品や技術を入手するために
-
X-Smilesブラウザーを見てみてください。これは、W3Cによる新しいクライアント技術（XHTML 2.0やSVG、XForms、SMILなど）の多くを、早期に（そして時には部分的に）サポートしている実験的なプラットフォームです。
著者について
記事の評価
| 
