XHTML の終焉と XHTML 1.0 Transitional 時代の思い出

その昔、XHTML という仕様がありました。1999年に HTML 4.01 が勧告されたのち、HTML はそれまでの SGML ベースから XML ベースの言語へ進化するため XHTML として再出発することになります。

2000年に勧告された XHTML 1.0 仕様の第1章では XML ベースにするメリットがいくつか挙げられていますが、もっとも大きなメリットは「標準的な XML ツールで閲覧、編集、検証ができる」という点でしょう。当時は HTML のパース方法に正確な仕様が存在せず、不正なマークアップの解釈はブラウザやライブラリの実装により異なっていました。そのため Web サイトのデータを XML パーサーで処理できることに期待が持たれていたという側面がありました。ブラウザや支援技術はもちろんですが、一般ユーザー（Web ページの閲覧者）にとっても、たとえばデータベース的な側面の大きいコンテンツでは HTML を XML として解釈できることで、わざわざ HTML パーサーのライブラリを導入せずともデータを二次使用することが可能になります。

しかし HTML を XML 化するには大きな、あまりにも大きな壁がありました。XML として解釈させるには「終了タグを省略しない」「属性値は必ず引用符で囲む」といった表記上のルールを遵守するだけでなく、MIME タイプも text/html でなく application/xhtml+xml 等にしなければなりません。ところが当時ブラウザの主流だった Internet Explorer は application/xhtml+xml を認識しませんでした。具体的には application/octet-stream と同じく、画面描画をせずにその XHTML コンテンツをファイルとしてダウンロードする挙動となっていました。一部の XHTML 推進者による個人サイトでは「ダウンロードしたファイルをローカルでブラウザ等に読ませれば閲覧できるのだから問題ない」として application/xhtml+xml での配信を行っていたサイトも存在したのですが（今も残っているのかな?）、企業サイトではそうもいきません。IE が application/xhtml+xml に対応したのは XHTML 1.0 の勧告から10年以上も経った2011年のバージョン 9 からであり、結局のところ当時の「Web サイトを XML パーサーで処理する」構想は幻想に終わりました。

ところが実際の Web 制作の現場では特別な理由のない限り XHTML 1.0 が採用されることになります。XHTML 1.0 では HTML 互換性ガイドラインに従ってマークアップをする限り、text/html で配信しても良いとされていたからです。

そのため XHTML 1.0 を採用しつつも text/html で配信することで Internet Explorer にも対応させるというのが当時の Web サイト制作の主流でした[2]。この場合、ソースコードの見た目上が XHTML ぽくなっていても XML パーサーで処理することはリスクを伴います。text/html で配信しているということは XML として Well-Formed になっていることが保障されていないのであり、実際そういったサイトは多くありました。XHTML 1.0 が勧告されても HTML 4.01 が廃止されたわけではないため、text/html で配信するなら HTML 4.01 を使い続けてもまったく問題なかったのですが、それではなぜ当時の Web 制作の現場では XHTML 1.0 が好まれたのでしょうか。個人的な推測ではありますが、その理由は以下の2点にあったと思います。

• 当時は HTML エディターや lint ツールが貧弱であり、プロジェクトごとの表記統一ルールを遵守させるためにルールの厳しい XHTML の採用は好都合だった（属性値を引用符で囲わない表記などはバリデートエラーになるため）
• 「これからの時代は XHTML だ」という業界全体の空気感があった

つまりユーザーのメリットを考えた結果ではなく、制作側の都合による面が大きかったということです。

前者の点は当時の制作環境からすればたしかに有用なものでした。しかし表記のみ XHTML にしたところで text/html で配信したのでは XHTML の本質的なメリットは受領できず、一部の都合良い部分を利用していたに過ぎません。IE も含めてすべての環境が XHTML に対応した段階で text/html での配信をやめて application/xhtml+xml に移行することこそが真の目標であり、text/html での配信はあくまで移行期間における暫定的な対応とされていました。

XHTML 1.0 に続けて 2001年には XHTML 1.1 が勧告されます。XHTML 1.0 は要素や属性は HTML 4.01 とまったく同じだったものの、XHTML 1.1 では Ruby Annotation Moduleが取り込まれたため、とくに日本語サイトにおいては XML 化のメリットに加えてルビが使えるメリットも生じました。

しかし XHTML 1.1 は世間ではほとんど採用されることはありませんでした。これも個人的な推測に過ぎませんが、その理由は3つ。

• XHTML 1.0 では条件付きで認められていた text/html が使えない
• リンクの target="_blank" が使えない
• 当時のブラウザの対応的にルビの導入は難しく、新要素追加のメリットを活用することができなかった

いまでもそうですが、外部サイトや PDF ファイルへのリンクには target="_blank" を付けるという謎の慣習があるため[3]、target 属性を使用不可にした HTML 4.01 と XHTML 1.0 の Strict DTD を採用することは難しく、また Strict 相当の DTD しか用意されていない XHTML 1.1 も必然的に採用しにくい事情がありました。

技術的にはこれらを回避して XHTML 1.1 を採用する方法は存在しました。text/html が使えないことに対する IE 対策としては、リクエストの Accept ヘッダーに application/xhtml+xml が含まれていればそれを返し、含まれていなければ text/html を返す「コンテントネゴシエーション」を行う手法があります。また、外部リンクは JavaScript の window.open() を使うことで target="_blank" なしに別ウィンドウを開かせることができます[4]。

しかしコンテントネゴシエーションはサーバー設定が必要、後者も JavaScript を書かなくてはならないコストが生じるのに対し、そこまでして XHTML 1.0 Strict や XHTML 1.1 を採用するメリットが見出せなかったためか、HTML5 が普及するまでは XHTML 1.0 Transitional の採用が続くことになります。

2008年に HTML5 の最初の草案が出された一方、XHTML 2.0の構想は中止され、世の中は XHTML の幻想から開放されて HTML5 への道を歩み出します。前述のとおり2011年には Internet Explorer 9 がリリースされ、ようやく全ブラウザが application/xhtml+xml に対応したことになるのですが、その時点で既に XHTML の熱は消え去っており、またいずれにせよ IE 8 以下が残り続ける限り application/xhtml+xml の採用は困難だったため、IE の XHTML 対応を歓迎する向きは皆無でした。

一方、HTML5 の仕様としては従来の XHTML との後方互換性を考慮したものとなっています。これには二つの意味があり、表記ルールと構文ルールの問題に分けられます。構文ルールは後述するとして、まずは表記ルールの方から。

これは HTML 構文（text/html 配信）でありながら空要素にスラッシュ（U+002F）を付けたり、真偽属性に値を設定したりしても良いというものです。特定の用語が HTML 仕様で定義されているわけではないですが、この記事では後述の「XML 構文」と区別するために便宜上「XML 表記」と呼称します。

改めて説明するまでもないと思いますが、以下のいずれも HTML5 では有効です。

<button disabled>Button</button>
<button disabled="">Button</button>
<button disabled=disabled>Button</button>
<button disabled="disabled">Button</button>

<hr>
<hr/>
<hr />

真偽属性のバリエーションは 2.3.2 Boolean attributesにおいて空文字列ないし属性名と同じ文字列を指定しても良いとされています。

空要素のスラッシュ表記は HTML 構文の 13.1.2.1 Start tagsにおいて、開始タグが空要素、MathML名前空間、SVG名前空間のいずれかの場合、スラッシュ（U+002F）を含めても良いと定義されています。スラッシュの前に空白を置くパターンは、もともとはスペースなし・スラッシュ付きの表記に対応していなかった Netscape Navigator 3 対策として行われていたものですが、ソースコード上の見やすさの理由からその表現を好む人も多いようです。

これらのことは XHTML 1.0 / 1.1 時代に作られたコンテンツの HTML5 への移行を容易にするだけでなく、新規に作成されるコンテンツにおいてもツールによる整形や自動生成において大きなメリットとなります。例えば著名なフォーマッターの一つである Prettier (v3.2.5) では HTML の空要素は自動的にスラッシュ付きに変換されます（Playground での実行例(prettier.io)）。ほかにも HTML の生成過程で XML + XSLT 処理を行ったり、フロントエンドフレームワークを使用した結果、XML 表記で出力されることもあるでしょう。

これは application/xhtml+xml のように XML として処理できるメディアタイプのことです。この場合、閉じタグは省略しない（空要素にはスラッシュを入れる）、属性値は必ず引用符で囲うといったことはもちろんですが、DOCTYPE の DOCTYPE 部分は大文字で表記する、ルート要素に xmlns 属性を設定する、言語設定は lang 属性でなく xml:lang 属性にするといった XHTML 1.0 / 1.1 と同じルールが適用されます。

<!-- HTML Living Standard で XML 構文を採用した場合の HTML 冒頭 -->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">

これは以前は「XHTML 5」とも呼ばれていましたが、現在は「XHTML」の用語は使用されなくなり、「XML syntax（XML 構文）」と呼ばれています。この XML 構文ですが、やはり以下のような理由からほとんど採用はされませんでした。

• Internet Explorer 9 がリリースされても 8 以前の利用者もまだ多かったため、前述のコンテントネゴシエーションを採用しない限り application/xhtml+xml での配信は困難だった
• HTML5 は DTD がないことにより、XML 構文においては名前文字参照が XML 実体参照で定義されている &, <, >, ", ' の5種類しか使用できない（© などは数値文字参照に書き換える必要がある）
• 外部スクリプトの実行やブラウザのアドオンなどが動作しない例が増えてきた
• 新しい技術が XML 構文に対応しない例が増えてきた

HTML 仕様としては XML 構文が定義され、上記の名前文字参照の例外を除けば XHTML 1.0 / 1.1 との後方互換性が確保されていたとはいえ、もともと application/xhtml+xml の採用率は著しく低かったこともあってか世間のサービスは XML 構文を考慮しないものがありました。HTML5 普及の少し前から Google マップ、YouTube、Twitter（現：X）といったサービスが台頭し、Web サイトにこれら外部サービスのコンテンツを埋め込むケースが増大しました。<iframe> 要素や <object> 要素による埋め込みであれば埋め込む側のページが HTML 構文であろうと XML 構文であろうと問題はないのですが、<script> 要素に外部サービスの URL を指定するタイプの埋め込み方法では XML 構文下で動作しないことがあります。

XML 構文では document.write() が動作しないのは周知のことと思いますが、X の投稿埋め込み（https://platform.twitter.com/widgets.js）が document.write() を使っているため、XML 構文のページでは埋め込みが表示されません。HTML vs XML MIME type(labs.w0s.jp)のページで実際の様子を見ることができます。

また私はブラウザのマウスジェスチャーとして Foxy Gesturesをインストールしているのですが、これは XML 構文のページで正常に動作しません。

さらに、新しい技術が XML 構文に対応しない例もあります。

<script type="module">
	const shadowRoot = document.getElementById('shadow-dom').shadowRoot;
	console.debug(shadowRoot); // XML 構文では `null`
</script>

<p id="shadow-dom"><template shadowrootmode="open"></template></p>

このコード例のように shadowrootmode 属性を持つ <template> 要素の親要素のシャドウルートを取得しようとしても、XML 構文では取得できず、Element.shadowRoot プロパティの返り値が null になってしまいます。こういったケースは今後増えてゆくでしょう。

このように様々な理由から、XML 構文を採用することはもはやデメリットの方が大きくなってきています。逆に当初メリットとして挙げられていた「XML パーサーによる処理」については、HTML5 において HTML のパース方法に統一的な挙動が定義されたことでそのメリットは限定的なものになってきました。

• HTML 仕様において XML 構文が非推奨であることが明文化されました。
• WHATWG の方針が変わったわけではありません。W3C HTML5 の当初の時点から HTML 構文を推奨する考え方でした。
• 推奨されないのはあくまで XML 構文（application/xhtml+xml による配信）です。<hr /> のように XML ライクな表記をすることは今後も問題ありません。
• XHTML 1.0 時代が採用されていた時代にも application/xhtml+xml による配信を行っていたサイトはごくわずかでした。今の時代にも XML 構文を採用しているケースはなおさら皆無といって良いでしょう。ほとんどのサイトでは今回の変更（仕様における非推奨の明文化）はまったく影響ありません。
• ブラウザ等が application/xhtml+xml のサポートを止めるわけではありません。application/xhtml+xml で配信しているサイトであっても、今すぐ対応が必要ということではありません。ただしそのようなサイトは新しい技術の導入が徐々に難しくなるなど、いずれ時代に取り残される恐れはあります。またアドオンが動かないなど、既にユーザーに不利益が起きている可能性も考えられます。