レベル: 初級 Adriaan de Jonge (adriaandejonge@gmail.com), Senior Java Software Engineer, SDB Java
2007年 11月 20日 HTML V5 と XHTML V2 はどちらも既存のバージョンを改善することを目的としていますが、その改善を行うために開発者が選択した方法は非常に異なっています。この両標準の異なる設計思想がもたらす結果も明らかに異なっており、ブラウザーの長い歴史の中で初めてのことですが、今後のブラウザーのバージョンの方向性が明確でなくなっています。この記事では、この 2 つの標準の詳細の背景にある、全体像を探ります。
大部分の人達は HTML V4 と XHTML V1 を使って Web ページを作成します。セマンティック HTML の概念や、HTML の構造の検証、そしてアクセシビリティーの向上のための文書の改善について理解しているのは、HTML を熱烈に支持する人の中でもかなり少数です。HTML 文書が持つ素晴らしい性質は、さまざまなトレードオフ、設計上の数々の選択、そして議論を数多く重ねた結果です。さまざまな批判はありますが、HTML の普遍性に比べると、他のものはその足元にも及びません。ほとんどのユーザーは、この HTML の標準をそのまま受け入れており、たとえ現在の HTML の標準が最終的なバージョンになってしまうとしても変わることはありません。
しかし他の標準と同じように、HTML には後継があります。今でも、専門家達は HTML の次期バージョンについて検討しており、現在のバージョンでの既知の問題をすべて解決しようとしています。そして、人々がグループとして集まる場合にはよくあることですが、この作業の将来の方向についても、専門家達の意見は一致していません。
新バージョンの HTML に関する最初の提案は、W3C によって立ち上げられたワークグループから提出されました。このグループの考え方は XHTML V2 を中心としていました。XHTML V2 は、より純粋な XHTML へ進むという、それまでの開発を継続したものであり、また最初のバージョンの HTML の設計思想に戻った標準です。
W3C とは別の、著名な HTML の専門家達 (ブラウザーのベンダーや Web 開発者、その他の利害関係者など) は XHTML V2 の方向性に異議を唱えました。彼らは 2004年に、次期バージョンの HTML のために別の方向性を提案すべく、独立したワークグループでの活動を開始しました。このグループは WHATWG (Web Hypertext Application Technology Working Group) という旗の下で、HTML V5 と Web Forms V2 に関する提案を取りまとめました。
それから数年後、このワーキング・ドラフトは、HTML の別の方向性を明確に記述したものになりました。2007年4月、W3C は、正式な勧告としては (まだ) 受け入れないものの、HTML V5 を検討対象として採用するという提案に関する投票を行いました。圧倒的多数が賛成でした。その結果、興味深い状況が生まれています。W3C は HTML と XHTML の後継に関して、競合する 2 つの仕様の作業を行っていることになります。理論的には、どちらの提案も合理的に正当化することができます。しかし現実には、これらの標準を主なブラウザーのすべてがサポートするまでには、数多くの障害を克服する必要があります。
これが、現在の状況に至るまでのありのままの事実です。2 つの提案の間での実際の相違点を巡って、さらに興味深い議論が行われています。この記事では、それぞれの提案の本質を大局的にながめ、次にそれぞれの考え方の詳細について調べることにします。
 |
頻繁に使用される頭字語
-
CSS: Cascading Style Sheets
-
HTML: Hypertext Markup Language
-
W3C: World Wide Web Consortium
-
XHTML: Extensible Hypertext Markup Language
|
|
XHTML の簡単な歴史
XHTML V2 の背景にある考え方を理解する前に、少し歴史を知っておく必要があります。1990年代の初め、最初のバージョンの HTML は SGML (Standard Generalized Markup Language) をベースにしていました。SGML との重要な違いは、World Wide Web の重要な基礎であり成功要因である、ハイパーリンク機能です。HTML は SGML と同様、作成者が文書の構造を記述することができ、段落やリスト (番号付きリストと番号なしリスト) からヘッダーを分離することができます。画面上の外観はブラウザーに依存していました。
Web が一般的になるにつれ、HTML のユーザーはページのルック・アンド・フィールをコントロールできるように要求するようになりました。ブラウザー・ベンダーは新しい機能を HTML V2 と V3 の中に詰め込みました。それに伴い Web ページは、ページのレイアウトを制御する主な方法として、利用しにくい複雑にネストした構造の表を使わなければならないものになってしまいました。そして文書の他の部分はフォント・タグや色の宣言などであふれ、元の文書構造を認識できなくなりました。
HTML V4 は、この混乱を収めるために設計されました。HTML V4 では、表示ロジックは CSS に外部化され、コンテンツの配置を高度な方法で行うためにレイヤー (DIV) が導入されています。これは HTML V3 からのパラダイム・シフトを意味します。この移行を簡単に行えるように、HTML V4 の Transitional バージョンは古い HTML V3 の構成をサポートしています。Strict バージョンは、上級の HTML 作成者向けに、コンテンツと表示の完全分離を強制しています。
当初の HTML V4 サイトは DIV を新たな万能ツールとして採用し、ページ・ヘッダーを含めて (しかしそれに限定することなく) ページの中で多少の装飾が必要なほとんどすべての要素に DIV を使用しました。HTML のスタイル属性は表示の詳細を記述するものとして一般的になりました。そして最終的に、必要以上に複雑な表はページから消えたのです。しかしコンテンツと表示ロジックは、どこを見ても相変わらず混在したままで、義務としての CSS ファイルには、ほんの数行しか含まれていませんでした。
もっと最近になると、一部の著名な Web 開発者達が、スタイルシートによるスマートな HTML V4 の使い方を奨励し始めました。最近のブラウザーでは、CSS のプロパティーは DIV 要素のみならず、すべての HTML 要素を任意の方法でスタイリングすることができるようになり、セマンティック HTML が話題に上るブログも多くなりました。ページの作成者は DIV 要素の使用を完全に禁止するのではなく、HTML 要素として、その要素が含むコンテンツを最も適切に記述できるものを使うようにしています。例えば、大部分の Web サイトに見られるナビゲーション・メニューを最も適切に記述するには、番号なしリストとして記述します。また、段落要素に対して bigHeader という名前のクラスを使うよりも H1 要素の方が好ましく、必要に応じて CSS を使って外観を変更します。
その間 W3C は、HTML V4 に等価なものとして、整形式で妥当な XML として書き直された XHTML V1 を提案しました。これによって XML ユーザーは、XML コンテンツを Web ページに変換し、既存のバリデーターを使って変換結果を検証する作業を単純化できるようになりました。XHTML V1.1 はコンサーン (関心事) を別のモジュールに分離しようとしています。このモジュール方式によって、標準の一部をさまざまな目的で再利用しやすくなり、また新しい機能で標準を拡張することも容易になります。
XHTML V1.1 のユーザーは、HTML V4 のユーザー以上にコンテンツと表示の分離を行います。しかしよくあることですが、いくつかの実際的な要件は CSS による裏技で解決する他にありません。例えば、番号なしリストとして記述されたメニュー構造は、通常は見栄えの良い画像で構成されています。しかし画像は、視覚障害者のための音声合成機器では容易に読み取ることができません。また、Lynx などのテキスト・ブラウザーは画像を適切に表示することができません。CSS による裏技を利用すると、ブラウザー上でテキストを隠し、画像を表示することができます。しかし、メニューのコンテンツがページごとに異なる場合には、そうしたコンテンツを CSS の中で指定するのはあまりスマートではありません。
XHTML V2 の背景にある考え方
XHTML V2 の背景にある、最も重要な設計思想は、コンテンツと表示の分離をさらに改善すること、そして HTML V4 と XHTML V1 に残っている問題を改善することです。XHTML V2 は、例えば番号なしリストの各項目に対する画像ソースの指定をネイティブ・サポートしています。以前の IMG SRC タグは、任意の要素に対して SRC を指定するオプションで置き換えられています。この変更によって CSS はコンテンツと無関係になり、通常の表示機器とは異なる機器でも画像の代わりにテキストを容易に表示することができます。
ただし Web 開発者にとって困難なものは CSS のみではありません。HTML のフォームによるサーバーとのやり取りや、何行もの JavaScript™ コードに大量の時間が費やされています。フォームは一次元のキーと値の対に制限されています。JavaScript コードの開発には大量の作業が必要ですが、音声合成機器など通常と異なるインターフェースでは、そうした作業も無駄になります。
モジュールによる方法の中で、XHTML V2 は HTML のフォームを XForms モジュールで置き換え、適切なアプリケーション・モデルを使うことによって、一般的なコンサーンに対するサポートを追加しています。XForms では、対話型ロジックや検証ルール、計算などを、1 行もスクリプトを書かずに指定することができます。またこの方法では、キーと値の対の代わりにリッチな XML 構造を使用しており、ネストしたサブ・フォームや繰り返し要素を使うことができます。音声合成機器は強力なエンジンを提供することの他に、アプリケーションの持つ表現力の豊かさを、より完全に表現することができます。
XHTML の定義からは、XForms 以外にも他のいくつかのコンサーンが、他の目的に再利用できる独立した仕様として抽出されています (例えば XML Events や XFrames、そして (アジア言語用の) Ruby (ルビ) など)。
表示部分に加え、プログラムによる変更が可能な部分も XHTML V2 の標準から分離されています。対話動作の属性 (onClick など) は XML Events モジュールで置き換えられています。XML Events 仕様は元々この目的のために設計されているため、ユーザーとの対話動作を処理するための強力なツール・セットを提供しています。
XHTML V2 で革新された部分を要約すると、中心的な思想はコンサーンの分離です。もはや各コンサーンは HTML の 2 次的な機能ではなく、新たな仕様にとっての第一目標です。その結果、この新しい仕様は現在の問題を対象として最適化されています。しかしコンサーンの分離は、現実的な目標というよりも設計思想上の目標です。完全なツール・セットを適切に使いこなせる技術スキルを持った賢明な開発者であれば、効果的な結果を実現することができます。しかし、現在のバージョンの HTML の平均的なユーザーが適切な品質の XHTML 文書を作成できるかどうかは、疑問があるところです。
XHTML V2 はほぼ、平均的な HTML 作成者を対象にしていません。しかし適切な開発者の手にかかれば、アクセシビリティーを十分に最適化した、非常にスマートなソリューションを XHTML V2 によって実現することができます。
HTML V5 の背景にある考え方
WHATWG は HTML V5 の設計にあたって、非常に実際的な手法をとっています。このグループでは、コンサーンの分離のような抽象的な理想を追求する代わりに、主なブラウザーにおける現在の実際の動作 (W3C の仕様とは異なっています) を文書化することから始めました。この分析を基礎として使うことで、HTML が実際にどう使われているかを調査したのです。
WHATWG は、HTML が実際にどう使われているかというこの情報を基に、平均的な Web 開発者の作業を楽にできる機能の提案を始めました。HTML V5 はこれまでのバージョンの HTML に元々あったものを尊重していますが、HTML の純粋さを高めることは第一の目標ではありません。例えば、文書をモデル化するという第一の目的は、Web アプリケーションの最適化という目標で簡単に置き換えられています。
Web アプリケーションの開発は、それをネイティブ・サポートするモデリング言語によって大幅に単純化することができます。例えば HTML V5 は、データ・グリッドやメニュー、ツールバーなどの対話型コンポーネントをネイティブ・サポートしています。デフォルト動作を持つ記述型の HTML 要素を使うことで、汎用の DIV による動作をシミュレートするための JavaScript コードの作成時間を大きく節約することができます。
HTML V5 仕様は HTML の要素と属性に限定されているわけではありません。この仕様では、文書の編集やドラッグ・アンド・ドロップによる対話動作など、特定の目的のための JavaScript API を指定しています。これはコンサーンの分離とはまったく正反対の方法です。この方法では Web 開発者にとって API は単純化されますが、仕様の規模は大幅に大きくなります。
XHTML V2 と XHTML V1 の間の違いに比べると、HTML V5 と HTML V4 とは似ています。移行はスムーズであり、HTML V4 の経験が豊富な開発者ならば容易に新しいバージョンに慣れることができます。新しい機能はこれまでと同じ論理に従っています。HTML エディターで、特定の要素のイベント属性を具体的に入力しようとすると、より適切なテキストが補完されます。
現在の Web アプリケーションは、Ajax (Asynchronous JavaScript + XML) によってサーバーと対話動作を行います。HTML V5 はサーバーとの対話動作の重要性を認識しているので、セキュリティーの問題を起こさずに、ネットワークを介して通信し、サーバーから受信されるイベントの処理を行い、そして他のドメインの文書にメッセージを送信する、いくつかの方法を指定しています。
HTML V5 の背景にある基本思想は、平均的な Web 開発者が必要とする実際的な機能によって HTML V4 を拡張する、ということです。HTML V5 は HTML V4 からのおなじみの方法を継続しつつ、技術を単純化しています。HTML V5 は HTML V4 の問題に対応するために、大幅な再設計をするよりも最小限の方法を取ろうとするのです。
新しい標準の実際の使用について
XHTML V2 とその関連モジュールは、W3C によって正式にサポートされており、この関連モジュールは、W3C が維持管理する他の XML 仕様の重要な要素になりつつあります。残念ながら、W3C が正式に承認したからといって主なブラウザーがサポートするという保証はありません。単純で標準的な XHTML V2 をサポートすることは大した問題ではありません。最近のブラウザーは既に多くの機能をサポートしています。XHTML V2 を適切に使えるかどうかは、関連モジュールが入手可能かどうかに依存します。この記事の執筆時点では、Microsoftが XML Events や XForms などの機能によって Windows® Internet Explorer® を拡張するかどうか、明確ではありません。XML Events をはじめとする Mozilla の XForms プラグインは、既に数年間も開発が行われています。XForms プラグインは、この技術の能力と実装の困難さの両方を実証しています。
HTML V5 の仕様は、実装に関する懸念事項を念頭に、ブラウザーのベンダーとの緊密なコミュニケーションによって作成されました。ただし WHATWG は、W3C が正式に承認するかどうかを疑問視しています。彼らの FAQ では、いつ正式に W3C に承認されるかを予想することすらしていません。W3C とは無関係に、ブラウザー・ベンダーは非公式な HTML V5 標準を実装してしまうかもしれません。ブラウザー・ベンダーが正式な勧告に先行したとしても、それは初めてのことではありません。
競合する標準
この時点では、まだ HTML V5 も XHTML V2 も、正式な勧告ではありません。一部の詳細は今後変更されるかもしれません。変わらないのは、それぞれの標準の現バージョンが持つ一連の問題に対して対応するという方向性です。将来のブラウザーが新しい標準それぞれに対するサポートをどう追加するのか、興味深いところです。現在のブラウザーは HTML V4 と XHTML V1 の両方をサポートしています。それと同様に、将来のブラウザーは HTML V5 と XHTML V2 の両方をサポートするかもしれません。この 2 つの標準の魅力は異なるものになると思われるからです。
もし皆さんが HTML V4 よりも XHTML V1.1 に関心があり、さまざまな機器で利用できる文書を作成するためにスマートな方法を探しているなら、おそらく XHTML V2 の利点に魅力を感じるでしょう。一方、XML に準拠していることから XHTML V1 しか使わないものの、HTML V5 での新しい機能を好ましいと思う人ならば、XHTML V5 (XML の方言として書き直された HTML V5) に魅力を感じるかもしれません。
HTML V5 に最も魅力を感じているのは、HTML V4 を使って対話型の Web アプリケーションを開発している人達です。また HTML V5 は、WYSIWYG (What You See Is What You Get) 機能を持つ文書エディターを使って管理されるサイトにとって、より現実的な代替手段にもなるはずです。ただし現状を考えると、HTML V4 と XHTML V1 は今後も長きにわたって使われることになりそうです。
参考文献 学ぶために
議論するために
著者について | 
| | Adriaan de Jonge はオランダのハーグにある SDB Professionals の Java 専門家チームの一員です。ライターとしての彼の経歴は、XForms と Ruby on Rails の比較で始まりました。彼は Java™ 開発者として、Web ベースとクライアント・サイド両方のフロントエンド技術に特に関心を持っています。連絡先は adriaandejonge@gmail.com です。 |
記事の評価
| 
