HTML5 の XML 的な部分

次世代の Web ネイティブ言語を扱う開発者に対する 6 つの推奨事項

Uche Ogbuji
配信 2010年 7月 06日/更新: 2010年 7月 08日

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です： XML 的思索

https://www.ibm.com/developerworks/jp/views/global/libraryview.jsp?series_title_by=xml+的思索

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です：XML 的思索

このシリーズの続きに乞うご期待。

2010年 7月 08日: 著者の要求により、「参考文献」に次の 2 項目、「ヒント: 常にXML宣言を使うこと」、そして Michael Smith 氏への謝辞を追加しました。

よく使われる頭字語

API: Application Programming Interface
DOM: Document Object Model
HTML: HyperText Markup Language
HTTP: HyperText Transfer Protocol
MIME: Multipurpose Internet Mail Extensions
SGML: Standard Generalized Markup Language
URL: Uniform Resource Locator
W3C: World Wide Web Consortium
XHTML: Extensible Hypertext Markup LanguageExtensible Markup Language
XML: Extensible Markup Language

HTML の歴史を見ると、節目ごとに大きな論争が起きています。Web アーキテクトによる最大限の努力にもかかわらず、Web は常に乱雑で混乱に満ちた、そして時には不愉快なほど不完全なマークアップで構成される荒野の辺境でした (これらのマークアップにはタグ・スープというニックネームがついています)。このため、XML によってこの混乱を整理し、XML を「Web の SGML」にする (SGML はメタ言語であり、HTML は SGML の 1 つの種類にすぎません) という期待が常に抱かれていました。XML は颯爽と登場し、そしてすぐに大きな反響を呼びました。W3C は、(当然のことですが) ブラウザーでも XML が成功するかもしれないと期待し、HTML よりも一貫性のある、最も自然な形で HTML から進化したマークアップ言語として、XHTML を提起しました。残念ながら、この野望を妨害する予想外の問題が次々に発生しました。名前空間やリンクといった一見単純な概念が、技術における政治的な争いの嵐に巻き込まれてしまいました。その結果としての論争や遅れから、ブラウザー開発者達は、XML は既知の問題の回避に役立つ可能性があっても、XML 自体が新たな問題や、場合によっては未知の問題を大量に含んでいる、と信じるようになってしまったのです。

XML が万能薬ではないことの証拠が山のようにあるわけではありませんが、厳密な XML ベースの道筋へと Web をマイグレートしようとすると、ブラウザー開発者達は常に苦労する羽目になっていました。それは 1 つにはタグ・スープを使用するレガシー・ページの量が膨大なためであり、また伝説的なコンピューター科学者の John Postel にちなんで名付けられた、ポステルの法則を考慮する必要があるためです。ポステルの法則は下記のように表現されています。

送信するものに関しては厳密に、受信するものに関しては寛容に

XML の厳密さはサーバー・サイドやデータベース・サイドでのポステルの法則と共通です (サーバーやデータベースでは、管理者が方針として厳密なポリシーを強制することができます)。その結果、XML はこの領域に活用されてきました。Web ブラウザーはおそらく、他からの情報を受け付けざるを得ないものの究極的な例です。そのため、XML とポステルの法則に関する緊張は、この領域で最も高まっています。

XHTML は死に、XHTML は永遠に

ここ数年、この緊張が非常に高まっていました。ブラウザー・ベンダーはこれまで、ほとんど W3C を無視し、HTML を進化させるために WHAT WG (Web Hypertext Application Technology Working Group) を設立し、HTML5 を作り上げました。W3C の XHTML をサポートする動きは停滞しました。W3C は当初、HTML5 の現実性を認識し、HTML5 の作業を継続する場を提供しました。そして結局、XHTML に関する作業を 2009年に終了することで、敗北を受け入れました。これが実際に XHTML の終わりを意味するかどうか、簡単に判断することはできません。確かに HTML5 は決して XML を使いやすく設計してあるわけではありませんが、HTML に対する XML シリアライズという形で、少なくとも表面的には XML をサポートしています。この記事ではこれを XHTML5 と呼ぶことにします。いずれにせよ、事態はとても片付いたとは言えず、それは以下のような HTML5 の FAQ のエントリーの 1 つを見るとわかります。

HTML 文書の中で使用する構文に注意すれば、その構文を XML パーサーで処理することはできますか？いいえ、できません。HTML と XML には重要な違いが数多くあり、構文解析の要件には特に大きな違いがあります。そのため、一方の構文解析用に設計されたツールを他方に使うことはできません。ただし HTML5 は DOM で定義されているため、ほとんどの場合は HTML シリアライズと XHTML シリアライズの両方があり、どちらを使っても同じ文書を表現することができます。ただし、後ほど説明するいくつかの違いがあるため、一部の HTML 文書を正確に XHTML 文書として表現することは不可能であり、また一部の XHTML 文書を正確に HTML 文書として表現することも不可能です。

これは Web での XML の将来に関心を持つすべての開発者にとって、非常に混乱しやすい状況です。この記事では、HTML5 の世界での XML の現状を示す現実的なガイドを提供します。この記事で対象とする読者は、私が「必死の Web ハッカー」と呼ぶ人達、つまり W3C 標準について詳しくはないものの、Web 上で XHTML5 を生成することに関心を持つ人達や、単純な方法で XHTML5 を利用したいと思っている人達 (つまり描画に関する膨大な複雑さを気にするよりも、情報を利用することに関心を持つ人達) です。正直なところ、適切な方法で XML を処理するよう長年主張してきた私にとって、ここに挙げる推奨事項の一部にはためらいを感じます。HTML5 が相変わらず W3C のワーキング・ドラフトであり、完全な勧告になるまでに少し時間がかかる可能性があることを忘れないでください。ただし HTML5 の機能の多くは安定しており、また Web では既に広く実装されています。

XHTML5 として認識されるように文書を提供する

残念ながら、悪い知らせは他にもあります。正式に定義されたものとして XHTML5 を使うことはできないかもしれません。なぜなら、一部の仕様の記述では、XHTML5 として解釈されるためには、その文書を application/xhtml+xml または application/xml という MIME タイプを使って提供する必要がある、とされているためです。しかしそのようにして文書を提供すると、完全リリースされたバージョンの Microsoft® Internet Explorer® では、その文書を表示することができません (他のすべての主要なブラウザーの最新のバージョンでは問題ありません)。現実的な唯一の解決策は、構文としての XHTML5 を text/html という MIME タイプを使って提供することです。これは本来、HTML5 仕様の一部に違反しますが、Internet Explorer をサポートしない場合を除き、やむを得ないかもしれません。さらにややこしいことに、これは例のワーキング・グループで非常に議論を呼んでいる点であり、少なくともいくつかのドラフトでは、この部分の表現が控え目になっています。Internet Explorer 9 のベータ版 (プラットフォーム・プレビューとも呼ばれます) は、XML という MIME タイプで提供される XHTML を完全にサポートしています。そのため、このバージョンが皆さんのユーザーに広まれば、この問題は解消されるはずです。それまでの間、Internet Explorer 6 またはそれ以前をサポートする必要がある場合には、この記事で紹介した対策でも十分ではありません。その場合は HTML 4.x を使い続けるしかありません。

必死の Web ハッカーへの推奨事項: 構文としての XHTML5 は、text/html という MIME タイプを使って提供する。

DOCTYPE の扱い

必死の Web ハッカーの視点から見て 1 つの良い知らせとして、XHTML5 では文書型宣言 (DTDecl) に関してあまり心配する必要がありません。XHTML 1.x と 2 では、悪名高い構成体 (<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> など) が必要でした。この構成体の最大の問題は、あまり優秀ではないプロセッサーはおそらく DTD の URL をロードしてしまい、その URL は望ましくないネットワーク操作かもしれないことです。さらに、1 つの URL が他の多くの URL を含んでおり、W3C のサイトから不必要なファイルを何十もダウンロードする羽目になることは珍しくありませんでした。時によると、W3C がホストするファイルにも問題があり、それによって非常にデバッグしにくい問題を起こすことがありました。

XHTML5 では、ファイルの中の XML の性質は完全に MIME タイプで決まり、すべての文書型宣言は実質的に無視されるため、文書型宣言を省略することができます。しかし HTML5 には最小限の文書型宣言として <!DOCTYPE html> が用意されています。この文書型宣言を使用すると、ほとんどすべてのブラウザーは「標準」モードに切り替わり、そして「標準」モードは (完全な HTML5 ではないとしても) 一般的に標準に準拠しており、動作の予測が可能です。HTML5 の文書型宣言が別のファイルを何も参照せず、従って従来の XHTML の問題を回避していることに注意してください。

必死の Web ハッカーへの推奨事項: XHTML5 では、HTML で最小限の文書型宣言 <!DOCTYPE html> を使う。

外部の DTD コンポーネントを使用するわけではないため、一般的な HTML の実体参照 (  や © など) を使うことはできません。これらの実体参照は XHTML の DTD で定義されますが、DTD は宣言されません。一般的な HTML の実体参照を使用すると、XML プロセッサーは「undefined entity (未定義の実体参照)」というエラーを表示して動作を停止します。名前指定による文字実体参照で安全なものは、<、>、&、"、' のみです。そこで、文字実体参照ではなく数字実体参照を使うようにします。例えば   ではなく   を使用し、© ではなく © を使用するようにします。

必死の Web ハッカーへの推奨事項: <、>、&、"、' を除き、名前指定による文字実体参照を使わないこと。

技術的に言えば、最初の推奨事項に従って文書を text/html として提供すると、HTML の名前指定による文字実体参照を使用しても大部分のブラウザーではエラーが起きませんが、この偶然に頼る方法は非常に不安定です。また XML を利用するのはブラウザーのみではないことを忘れないでください。ブラウザー以外の XML プロセッサーは、上に挙げた文書を処理することはできません。

名前空間の扱い

XML フォーマットを認識するための精巧すぎるメカニズムのうち、MIME タイプと文書型宣言に続く最後のレイヤーは、名前空間です。皆さんはおそらく、通常は以下のような行で XHTML 文書を開始しているはずです。

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

太字の部分 (xmlns="http://www.w3.org/1999/xhtml") は名前空間です。XHTML5 では、この名前空間は相変わらず必要です。他の XML 語彙 (SVG: Scalable Vector Graphics など) を含める場合には、そうした語彙をそれぞれが要求する名前空間の中に配置します。

必死の Web ハッカーへの推奨事項: XHTML5 文書の先頭に必ずデフォルトの名前空間を含め、また、埋め込まれた他の XML フォーマットに対し、適切な名前空間を使う。

実際に他の語彙を含める場合、それらの語彙の名前空間宣言は、埋め込まれたセクションの最も外側の開始タグの中になければなりません。html 要素で名前空間を宣言すると、text/html という文書タイプに違反することによるエラーが起こります。

XHTML5 コンテンツを扱う

XHTML5 ではメディア・タイプを指定する必要があります。この指定は、Unicode BOM (Byte Order Mark) と呼ばれる特別な文字マーカーを使ってプロトコル・ヘッダー (HTTP の Content-Type ヘッダーなど) の中で行うか、または XML 宣言を使って行います。競合しない限り、この 2 つの方法を自由に組み合わせることができますが、問題を避けるための最善の方法は、メカニズムの組み合わせ方法に注意することです。残念ながら、XML 宣言を使う方法には潜在的な問題があります。XML 宣言を使うと、Internet Explorer のバージョン 8 またはそれ以前のバージョンはすべて Quirks モードに切り替わり、描画がおかしくなるという、悪名高い問題が発生します (Internet Explorer はこうした問題で有名です)。

必死の Web ハッカーへの推奨事項: XHTML5 文書には Unicode エンコードのみを使う。文書の先頭には XML 宣言を使わず、UTF-8 エンコードを使用するか、または UTF-16 の Unicode BOM (Byte Order Mark) を使う。文書を提供する場合には、可能であれば HTTP の Content-Type ヘッダーを使う。

下記はそうした HTTP ヘッダーの例です。

Content-Type: "text/html; charset=UTF-8"

新しいセマンティック・マークアップ要素

HTML5 では、コンテンツの構造の意味体系を明確にする新しい要素が導入されています (section や article など)。これらの要素は HTML5 の一部ではあっても変更される可能性がありますが、変更はおそらく大幅なものではなく、新しい要素を使用するリスクと、それらの要素によって表現が改善されることによるメリットは同程度です。1 つの問題は、Internet Explorer がこれらの要素を DOM の中に作成しないことです。そのため JavaScript を使用する場合には、別の対策を使う必要があります。幸い Remy Sharp が JavaScript による修正を維持管理しており、この修正を適用することができます。そのためには文書の先頭に以下のスニペットを含めます (リンクは「参考文献」を参照)。

<!--[if IE]>
<script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

また、これらの要素に対する CSS 規則も定義する必要があります。これはいずれかのブラウザーが HTML 4 形式で文書を描画してしまう場合に備えるためです (HTML 4 形式の場合、未知の要素はデフォルトでインライン描画されます)。下記の CSS であれば動作するはずです。

header, footer, nav, section, article, figure, aside {
    display:block;
}

必死の Web ハッカーへの推奨事項: 新しい HTML5 要素を使う場合には、それらの要素をサポートする HTML5 shiv による JavaScript とデフォルトの CSS 規則を含めること。

推奨事項のまとめ

たくさんの推奨事項を別々に挙げてきたので、それらを完全な例としてまとめましょう。リスト 1 は、今まで挙げた推奨事項を満たす XHTML5 です。これを HTTP 経由で提供する場合には、Internet Explorer をサポートしないという余裕がある場合を除き、ヘッダーとして Content-Type: "text/html; charset=UTF-8" を使います。Internet Explorer をサポートしない場合には、ヘッダーとして Content-Type: "application/xhtml+xml; charset=UTF-8" を使います。

リスト 1. 完全な XHTML5 の例

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
  <head>
  <title>A micro blog, in XHTML5</title>
  <style>
<!-- Provide a fall-back for browsers that don't understand the new elements -->
header, footer, nav, section, article, figure, aside {
  display:block;
}  </style>
  <script type="application/javascript">
    <!-- Hack support for the new elements in JavaScript under Internet Explorer -->
    <!--[if IE]>
      <script src="//html5shim.googlecode.com/svn/trunk/html5.js"></script>
    <![endif]-->
  </script>
  <script type="application/javascript">
    <!-- ... Other JavaScript goes here ... -->
  </script>
  </head>
  <body>
    <header>A micro blog</header>
    <article>
      <section>
        <p>
          There is something important I want to say:
        </p>
        <blockquote>
          A stitch in time saves nine.
        </blockquote>
      </section>
      <section><p>By the way, are you as excited about the World Cup as I am?</p>
      </section>
    </article>
    <article>
      <section>
        <p>
          Welcome to my new XHTML5 weblog <img src="/images/logo.png"/>
        </p>
      </section>
    </article>
    <aside>
      <header>Archives</header>
      <ul>
        <li><a href="/2010/04">April 2010</a></li>
        <li><a href="/2010/05">May 2010</a></li>
        <li><a href="/2010/06">June 2010</a></li>
      </ul>
    </aside>
    <footer>&#169; 2010 by Uche Ogbuji</footer>
    <nav>
      <ul>
        <li><a href="/">Home</a></li>
        <li><a href="/about">About</a></li>
        <li><a href="/2010/06">Home</a></li>
      </ul>
    </nav>
 </body>
</html>

リスト 1 は先頭で、HTML5 の文書型宣言を使用しており、またデフォルトの名前空間を宣言しています。この例の style 要素と script 要素は、実際のブラウザーの問題に対する対策を提供しているにすぎません。他の JavaScript を使用する場合にのみ script 要素が必要です。この文書は HTML5 の新しい要素を大量に使用していますが、それらの要素は必ずしも XML の性質に関係するわけではないため、ここでは詳細は省略します。img 要素に空要素の構文 (つまり /> で終わる要素の構文) が使われていることと、著作権記号に数字実体参照形式 (©) が使われていることに注意してください。

表 1 は、上記の例がさまざまなブラウザーでどのように動作するかを要約したものです。

表 1. この記事での推奨事項を満たす XHTML5 に対する各ブラウザーによるサポート

ブラウザー	動作
レガシー・ブラウザー (Internet Explorer 6.x またはそれより前のバージョン、Netscape、Firefox 1.x など)	どのように描画されるかは予測できません。例えば空要素は誤って終了タグと見なされるかもしれません。HTML の名前指定による実体参照を使用した場合、エラーは発生しません。
Internet Explorer 7 または 8	MIME タイプが `text/html` のため、描画は通常の「タグ・スープ」型 HTML として行われますが、文書型宣言があるため、Internet Explorer にあるような「標準モード」がトリガーされます。HTML の名前指定による実体参照を使用した場合、エラーは発生しません。
最新の、HTML5 対応ブラウザー (Firefox 3.x や Safari 4、最新の Opera や Google Chrome など)	MIME タイプのおかげで (XHTML5 ではなく) HTML5 として描画されますが、「標準モード」で描画されます。HTML の名前指定による実体参照を使用した場合、エラーは発生しません。
標準的な XML 1.x プロセッサーすべて	MIME タイプは考慮されません。パーサーは XHTML 名前空間の中で、すべての要素を一般的なものと見なします。いい加減な HTML の名前指定による実体参照を使用した場合、エラーが発生します。

まとめ

最近の重要な進展の 1 つとして、W3C の HTML ワーキング・グループが最初の正式ワーキング・ドラフト「Polyglot Markup: HTML-Compatible XHTML Documents」を公開しました (「参考文献」のリンクを参照)。このドラフトを公開したのは、より正確で完全な、最新の XHTML5 の基礎を提供するためです。

繰り返しますが、この記事で多くの推奨事項を挙げるに当たり、私はためらいを感じました。こうした対策は長年の苦しい体験から得られたものであり、実際の HTML の世界に XML を混在させる場合に起こりがちな、再現困難なバグや奇妙な互換性欠如といった悪夢を避けるための唯一の方法でもあります。こうした推奨事項を挙げたからと言って、私が XML の設計やベストプラクティスに関する注意喚起をやめたわけではありません。ブラウザーに接続される最も外側のコンポーネントのみに XHTML5 を使うことがベストです。XHTML のバリエーションはすべて、情報を含む言語と見なすよりも描画用の言語と見なした方が適切です。システムの大部分では他の XML フォーマットでメインの情報を伝達し、最終時点でのみ XHTML5 に変換すべきです。たとえ最終時点であれ、XHTML5 を作成する意味があるのか、と思う人がいるかもしれませんが、作成するものに関しては厳密さを推奨するポステルの法則を思い出してください。ブラウザー用に XHTML5 を作成することで、他の人が皆さんの Web サイトやアプリケーションから情報を抽出しやすくなります。マッシュアップ、Web API、データ・プロジェクトというこの時代には、XHTML5 を作成しておくことは価値あることです。

この領域での最近の進展に目を向けるよう指摘してくださった Michael Smith 氏に感謝いたします。

ダウンロード可能なリソース

このコンテンツのPDF

目次