必要があれば、仕様書とセットで読めば、理解が深まると思います。
この文書の唯一の正式文書（の最新版）は、英語版のhttp://www.w3.org/MarkUp/2004/xhtml-faqにあります。そして、この文書はその私的な日本語訳文書です。
この文書は随時修正される可能性があります。
この文書はあくまで参考程度であって、和訳内容には誤訳が含まれる可能性があり得ますので、ご利用の際は自己責任でお願いいたします。なお、誤訳がある場合はhttp://past.openvista.jp/blog/article/2004/08/xhtmlfaq.phpにてお知らせ頂ければ幸いです。
注釈は、クラス名my_annotationでマーク付けをしていて、視覚系UAでは地の文とは違った表示がなされます。
この文書の原文の著作権はWorld Wide Web Consortium（マサチューセッツ工科大学・フランス国立情報処理自動化研究所・慶應義塾大学が保有しています。詳しくはフッターをご覧下さい。
2次著作権については、本サイトのライセンス（クリエイティブコモンズ）とは一部合致しない点がありますのでそれは適用いたしません。なお、この文書は specification( 仕様 )では無いので、転載はできません。
原版著者: Steven Pemberton,W3C/CWI
このバージョンの策定日: 2004年 7月 21日
その他の関連FAQ:
この文書へのコメント、または問題やFAQの題名に対する提案がある場合はwww-html-editor@w3.orgへメールをお送りください。
訳注: ちなみに、分かっていることだとは思いますが、この翻訳の正誤に関してはこのアドレスには決して苦情などを寄せることがない様にしてください。
application/xhtml+xml に対応しているブラウザはどれですか?application/xhtml+xml に対応しているんでしょうか?text/html で送ってはいけないのでしょうか?target 属性が削られたのはなぜでしょうか?<img> が <object> に置き換えられようとしているのはなぜでしょうか?HTMLはおそらく、世界中で一番うまくいっている文書のマーク付け言語です。しかし、XML導入時は、それに適合したHTMLの新しいバージョンが必要かどうか議論すべく2日間に渡る研究会が計画されたこともありました。その研究会での結論は明快で「イエス」 - つまり、XMLベースのHTMLを用いれば、他のXMLでマーク付けされた言語はXHTMLの一部分を取り込むことが出来るし、XHTML文書は他のマーク付け言語の一部分を取り込むことができる。 - ということでした。この新バージョンでの改良で、 HTMLに取り込まれた見栄えを定義するなど本来の目的とは異なった要素などの雑な部分を廃止して改めていき、かつ新しく、必要とされている機能性を備え、よりよい形式にしていけるのです。
あなたの文書型がもし（他のマークアップ言語を含まない）完全なXHTML 1.0なのであれば、まだ特に大きな違いを感じることはないと思います。 しかし、より一層XMLツールが利用できるようになっていけば、文書の変換例: XML文書をXSLTでHTML文書に変換に用いるXSLTといったように、XHTMLを使うメリットに気づき始めることでしょう。XForms を例に取れば、（それを用いることで）単純な操作方法でXHTML文書（あるいはその他のXML文書）を編集したりできるのです。セメンテックなウェブアプリケーションはXHTML文書を活用出来るようになるでしょう。
もしあなたの文書が、MathMLやSMILやSVGといったように、XHTML 1.0以上の文書型であるなら、HTMLといった文書型では得られないメリットが、もう眼の前にあるのです。
ダメです。HTMLはXMLの形式を取っていません。文書をXMLとしてアクセスさせる前に、HTML文書を XML に適合するように変更しなければいけません。
訳注: 実際どうすれば、XMLに適合する形になるかは、XHTML について [WEB ARCHIVES]（例）をご覧ください。
HTML Tidyは全てのHTML文書をXHTML文書に変換するオプションがあります。また、Amayaブラウザ・エディタはHTML文書をXHTML文書として保存できます。
訳注: kanzaki.com - XHTMLの書き方と留意点 - 従来のHTMLをXHTMLに変換するための若干のヒントではHTML文書をXHTMLに変換するPerlスクリプトが配布されています。またHTMLtoXHTMLというJavaを利用したツールもあります。
これに関してはじっくりと考えてみることにしましょう。ブラウザはHTMLに関してはとにかく送られてきたものがどんなものでも、正しくあろうともなかろうとも、とりあえず受け入れて、実用本位と言うことで間違った文書にはエラー訂正をしつつ出力しようとするのです。こうしたエラー訂正をしていると、ブラウザはとてもレンダリングしづらいし、全てのブラウザで同じ結果を得ようなんてのは酷なことです。また、このようにブラウザが寛容であるから、ブラウザで見えるから大丈夫と、ブラウザが訂正しているそのエラーに気づくことなく、膨大な量の間違ったHTML文書が作られきたのです。こうして、文書がしばしばHTMLとして不十分なので、新しいレンダリングエンジンの登場は途方もなく困難になっているのです。
全てのブラウザは正しく書かれたHTML文書は処理方法は知っています。しかし、HTML文書が正しくなかったとしたら、ブラウザがエラーの箇所を補正しなければなりません。また、全てのブラウザが同様の補正をするわけではありませんから、ブラウザ間の表示や動作の結果が違ってくることになります。現在それぞれ異なる数百ものブラウザがあるわけで、その数は増加の一途をたどるわけですから（PCだけではなく、PDAや携帯電話、テレビやプリンターに加えて冷蔵庫までもが）、あなたが書いた文書を全てのブラウザでテストするなんて事はできないわけです。もし正しくないHTML文書を書いていて、特定のブラウザでうまく表示や動作が出来ていないのであれば、それはあなたのミスであって、もし正しいHTMLで書いていればそんなことは起こらないわけで、それはブラウザのバグなのです。
訳注: つまり正しいHTMLを書いた上で、ブラウザのバグ・・特にInternet Explorer (Windows)のバグに気を付けた方がよいでしょう。
W3Cはマークアップ検証サービスを提供しています。Amayaブラウザは、さらに（そのマークアップの妥当性に関して）太鼓判を押してくれます。
訳注: Another HTML Lintという国産の優れたチェッカもあります。ただ、チェッカーのチェック範囲には限界があることを念頭に置いていて下さい。
ブラウザは確かにHTMLやXHTMLを利用する時には重要ではありますが、そういった文書を読むプログラムはブラウザ以外にもあるのです。検索エンジンは文書を読みますけどブラウザではありません。それらを総じて「ユーザーエージェント」と呼ぶことで、この世界にはインターネット上の文書を利用するいろいろなプログラムがあることを人々に思い出して頂こうとしているのです。
例を挙げれば、あなたがよくGoogle検索をするのであれば、検索結果の下の方で「このページはフレームを使用していますが、あなたのブラウザはフレームに対応していませんあるいはフレーム対応のブラウザでご覧下さい」といったような記述を見かけることがあると思います。こういう結果を見た人はおそらくフレームに対応しているブラウザを使っている人も含めきっとこのリンクをクリックせずに通り過ぎていくことでしょう。こういう問題となるウェブサイトを作っている人は、訪問者はブラウザを使ったユーザーだけではないことや、また、誰かがあなたのサイトを検索した時にそのような記述を見て、マヌケに見えない様に、<noframes>要素内容にもっとマシなテキストを入れるべきである、ということには気づかないのです。
HTML初期には、各団体・会社によってHTMLに独自拡張の要素・属性が付け加えられました。このため、HTMLは混沌としてしまい、相互互換性の無い、それぞれ異なったバージョンが出来ていってしまったわけです。XML（このXはeXtensible、つまり「拡張可能」と言う言葉の略です）は誰でも、言語に依らず様々な要素を使うことが出来るのですが、ブラウザやその他のユーザーエージェントは、どの要素がどの言語のものか知っておかないといけませんし、あなた=ウェブサイト制作者はその事をそれらに伝えてやらねばならないのです。名前空間はちょうどそのようなことをしてくれる、というわけなのです。
text/html で送ってもいいんでしょうか?XHTMLは型としてはXMLの形式です。これはつまり、厳密に言えば、XMLに関連したメディアタイプ（application/xhtml+xml,application/xmlまたはtext/xml）で送ってやるべきだと言うことです。けれども、XHTML 1.0はレガシーなHTMLユーザーエージェントの互換性を慎重に考慮して策定されました。もしあなたが、シンプルなガイドラインを探しにいったら、text/html メディアタイプしか解釈しないレガシーなブラウザでも、きちんとした結果が得られるXHTML 1.0文書が多く手に入れられるのは、このせいです。だからあなたがXHTML 1.0文書を、それらに送る時のメディアタイプは text/html でないといけません。しかしXHTMLドキュメントを text/html で送信するということはそういったブラウザでは文書をXHTML文書ではなくHTML文書として認識されることをよく知っておいてください。
application/xhtml+xml に対応しているブラウザはどれですか?我々がよく知っているブラウザとしてはMozillaやNetscape 5以上やGaleonもしくはFirefoxといったMozillaベースのブラウザが対応していて、他にも同様に有名なのがOperaやAmayaやCamino（旧Chimera）にDocZilla、それにiCabやSafariにWAP2対応の携帯電話もそうです。実の所、最近のブラウザはどれもが対応しているわけです。それらの内、大体はXHTML文書をapplication/xmlと送られることに対応しています。詳細はXHTML
メディアタイプのテストをご覧ください。
していません。しかし、トリックを施すことで Internet Explorer にXHTML 1.0文書を application/xml で送り出す事が出来ます。
文書の先頭に次の太字=強調になっている行を付け加えてください。
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
copy.xsl の中身は以下:
<stylesheet version="1.0"
xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="/">
<copy-of select="."/>
</template>
</stylesheet>
このファイルは参照元のXHTML文書と同じサイト内=同ドメイン内?になければならないことに注意してください。
あなたが文書をXML文書として送っていて、その文書がXMLとして解釈されているのとしたら、このトリックを使うとブラウザは text/html の文書を受け取ったと考えてしまいます。だからあなたはXHTML 1.0文書を送るにあたっては、レガシーなブラウザへの送信方法に関する多くのガイドラインに従わないといけません。
そうすれば、あなたのXHTML文書は application/xml に対応しているブラウザであれば引き続き、うまく表示・動作するでしょう。
適用されません。HTMLのみに適用されるCSSのルールは text/html で受け取った文書にのみ適用されることになります。
訳注: XHTML 1.0勧告書中のAppendix C-13（同・有志日本語訳）を参照ください。
動きません。XMLでは別の方法を使うよう決められているからです。パーサーがマークアップされた文書をパースしている最中に、スクリプトによってマークアップが新たに生成される様なトリックは、使うことが出来ません。
XHTMLでも同じ結果を出すことはできますが、要素を増やしたり減らしたりする場合はDOMを用いないといけません。
text/html で送ってはいけないのでしょうか?XHTML 1.1は完全なXMLですから、XMLであるようにのみ送信されます。レガシーなブラウザに対しては、XHTML1.1を確実に読めるように送ることは出来ません。それゆえXHTML 1.1文書は、application/xhtml+xml といったXMLに関連したメディアタイプで送られなければならないのです。
訳注: 具体的にはXHTML1.1ではname属性やlang属性が廃止されたりしています。古い携帯電話のブラウザなどは、こういうのに対応していなかったりするわけです。
target 属性が削られたのはなぜでしょうか?そうではありません。XHTML 1.0には、strict・transitional・framesetと、3つのバージョンが存在し、この全てのバージョンは、できるだけHTML 4.01との互換性を考慮した上で、慎重にXMLへ適合させています。XHTML 1.1はXHTML 1.0strictや target 属性が残っているHTML strict（存在しませんが）をより厳密にしてアップデートしたバージョンです。
その他、transitional と frameset という2つのバージョンは、アップデートをするところがないですのでなされません。もし target 属性を使いたいのなら、XHTML 1.0 transitional を使って=宣言してください。
XHTMLのモジュール化はXHTMLを普通に使っている人ではなく、XHTMLベースの言語を開発する人を対象にしています。 過去に、ブラウザを製作する会社・団体が、時に基礎レベルにおいて相互互換性が不在な彼ら独自のバージョンのHTMLやXHTMLを開発しがちな点が見受けられました。
XHTMLのモジュール化というのは、新たな言語を作る際に、XHTMLを個別に選択できる多数のモジュールに分けるということです。モジュール化によっても、XHTMLベースである言語は何れも、（XHTMLから）逸脱するバージョンではなく、テーブルは本来の表と同じ意味で用いるものと決められているのです。また、モジュール化はどの部分に新しい要素を作るのがいいか、またそうでないかがはっきりさせることにもなるでしょう。
HTMLやXHTMLで便利なサービスを提供することは出来ますが、改良できる点は山積みです。注目されている点は、さらに望ましい（文書の）構造化の可能性やXMLと重複している機能の削除、ユーザビリティ及びアクセシビリティの向上や国際的な問題の解決、あらゆるデバイスへの対応とより良いフォームの導入、そしてスクリプトに対する依存性の減少といった点です。
訳注: あらゆるデバイスへの対応についてはDevice Independence Activityをご覧ください。
<img> が <object> に置き換えられようとしているのはなぜでしょうか?
そうではありません。<img> はXHTML 2で置き換えられようとしていますが、それはまた別の物です（<object> を使いたいのならそうすることも出来ますが）。
HTMLで用いられる <img> は設計にいろいろと問題があります。
<img> は空要素であるためその中に、データを書くことが出来ません。例えば、もしあなたがPNG画像を使ったとして、それをブラウザで表示させようとした時にブラウザがそれを扱えなかった時の代替は alt 属性のテキスト以外にないのです。この事によって、制作者は誰でも画像が見られることを重視して、ウェブでの最小公分母である画像形式つまりGIFやJPG画像等のある種枯れた形式を使い続けるようになったので、それらの形式より数々の点で優れているPNG画像は普及に後れを取ってしまったのです。alt 属性のテキストはマークアップが出来ませんので、そのテキストはプレーンなテキストとしてしか表示されません。longdesc 属性は、画像が見られない閲覧者への画像の説明に使うことが出来ますが、そういったlongdesc属性の存在をアピールするといったような実装はユーザーエージェント側にはほとんどなされていません。
XHTML 2では、言ってみれば画像はコンテンツの一つです。具体的には、任意の要素に src 属性が入れられるようになります。それはどういうことかというと、画像が取得できて、ブラウザが（その形式の画像を）処理出来る場合はその画像を表示して、無理な場合はその要素内容を使います。例えば…
<p src="map.png">駅を出て左折後に <strong>メインストリート</strong>を直進して下さい。</p>
こうしておけば、長所として（ネットワークの障害といった）何らかの理由で画像を取得出来なかった場合や、その画像に対応していなかった場合でも、文書が利用できるのです。あなたが複数の画像形式を提供したいと考えているのなら、こうしてみて下さい…
<p src="map.png"><span src="map.gif">駅を出て…</span></p>
あなたのサーバーがコンテントネゴシエーションをサポートしているなら（たいていはしていますが）、使ってみるのが得策です…
<p src="map">駅を出て…</p>
サーバーは、ブラウザが対応している画像形式に応答して、最適な形式を判断してそれを送ります。この時、もし画像が利用できなくても、その画像の要素内容が用いられます。（ページの作成後に）サーバーに（ある同じ画像とは）別の画像形式を追加した時、（その画像を利用させるために）ページを編集しなくてもうまくいくという長所もあります。
訳注: コンテントネゴシエーションはサーバーがApache等を使用していれば利用することができます。
XLinkとXHTMLはリンクするということへの要求が異なっているので、共存ができないのです。
そうはいいますが、過去、HTMLにバージョン毎の後方互換性がどんなにあったことでしょうか。
初期に策定されたHTMLのバージョンは独自の目的を持った言語だったので、古くなったブラウザでも新しい（HTMLのバージョンの）文書が利用できるように、新しいバージョンを策定するたびにその前のバージョンの互換性を保証することが必要だったのです。例を取れば、<meta> 要素において、古いブラウザで現れれないよう、内容は要素の中身ではなく属性値となっています。
しかし、XMLとスタイルシートのおかげで、strictな要素のように後方互換性を持たせる必要性はなくなりました。この記事が書かれた時点でのブラウザの95%以上がXMLベースであり、そういったブラウザはアップデートをせずとも新しいマーク付け言語を処理することが出来るのです。 XHTML 2は、それに対応するよう予めプログラムされていなくても、大部分が既存のブラウザでも充分に動くのです。 しかし、大部分ということは全てではありません。HTMLでは、フォームやテーブルが追加された時、閲覧者はブラウザの新バージョンを待たないといけませんでした。それと似た様なことで、XFormsやXML eventといったXHTML 2の一部機能に関しては、ユーザーエージェント側の対応を待つことになります。
訳注: XFormsに関しては、Mozilla等の開発を行うMozilla Foundationが開発プロジェクトを発表しています。
xml:space 属性は出力ではなく入力に関係していて、つまりは、DOM（ブラウザ内の文書のバージョン）中の空白をどうするかをコントロールするのです。ですから、あなたの画面上には何の変化もありません。
出力における空白の操作はCSSの'whitespace'プロパティによってコントロールできます。DOM中の空白は、この値を'pre'にすれば表示され、'normal'にすれば無視されます（CSS 3ではもっと高度なコントロールをするために多くのプロパティが加えられる予定です。）
これがXHTML 2で全要素にxml:space="preserve"が指定されている理由です。
しかし、CSSでは'whitespace'プロパティでは何の効果も得られませんし、表示されている空白をコントロールするwhitespace' 属性は<pre> 以外の全ての要素が、デフォルトでは 'normal' に設定されていますが、それらは自由に変更出来ます。
Copyright©2004 W3C®(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.