それでは、XHTML5はどうなりましたか？

http://www.w3.org/TR/html5/

そのページはxhtml5とhtml5の両方のドラフトですか？これらのDoctypeには違いはありませんか？

2012年の執筆時点で、W3CはHTML 5のXHTMLを放棄することを決定したことが明らかでした。この決定は、いくつかの理由により動機付けられました。

• XHTMLに本当に興味を持っている人はわずかでした。ほとんどのWebサイトはプレーンHTMLで記述されています。

• XHTMLが何であるか、そしてそれをどのように使用するかを本当に理解している人はさらに少なかった。XHTMLを提供するふりをしたWebサイトが多すぎて、の代わりに間違ったヘッダーを使用していましたContent-Type: application/xhtml+xml。

• XHTMLが何であり、ヘッダーが何である必要があるかを完全に理解している場合でも、application/xhtml+xmlコンテンツタイプを受け入れない/サポートしない一部のくだらないブラウザーでは非常に注意が必要です。つまり、ブラウザに応じてヘッダーを変更する必要がありました。

• XHTMLのXML部分も、開発者が解決しなければならない奇妙な状況を引き起こしました。1つはINVALID_STATE_ERR: DOM Exception 11、HTML文字（などé）を含むテキストをXHTMLページ内の要素に割り当てると表示されるメッセージです。AJAXリクエストを実行した後、大規模なWebアプリケーションで非常に役立つメッセージでこのエラーが発生した場合、それがJQuery、AJAX、または他の何かのせいであるかはまったくわかりません。

• HTML 5コードを記述することは、タグをあちこちに混在させることを意味しません。XMLとXHTMLに興味がある場合でも、XMLに非常に近いHTML 5コードを作成できます。

• 携帯電話の初期の頃、XHTMLはあまり強力ではないモバイルデバイスにとって興味深いものでした。XMLの解析はHTMLよりもはるかに簡単です。現在、デュアルコアモバイルデバイスでは、クリーンで有効なXMLを解析する必要があるか、ハッキングやタグが混在するダーティHTMLを解析する必要があるかは、実際には関係ありません。

2014年10月の仕様では、XHTML構文に言及しています。現時点では、（構文ではなく）新しいXHTML 言語のようなものがあるかどうか、もしあれば、XHTMLの位置はどうなるか、また主流のブラウザーによる新しいXHTML標準の採用は不明です。

XHTML5 は、「XMLとしてシリアル化されたHTML5」の同義語です。

この抽象言語を使用するリソースを送信するために使用できるさまざまな具体的な構文があり、そのうちの2つがこの仕様で定義されています。

...

2番目の具体的な構文は、XMLのアプリケーションであるXHTML構文です。ドキュメントがapplication / xhtml + xmlなどのXML MIMEタイプで送信されると、WebブラウザーによってXMLドキュメントとして扱われ、XMLプロセッサによって解析されます。著者は、XMLとHTMLの処理が異なることに注意してください。特に、わずかな構文エラーでさえ、XMLとしてラベル付けされたドキュメントが完全にレンダリングされるのを防ぎますが、HTML構文では無視されます。この仕様は、「XHTML 5」として知られるXHTML構文のバージョン5.0を定義しています。

• http://www.w3.org/TR/html5/introduction.html#html-vs-xhtmlから引用; また、「このセクションは規範的ではありません」と書かれていることに注意してください。

また、HTML5ポリグロット（通常のHTML5とXMLの両方としてシリアル化できるページ）の記述に関する素晴らしいドキュメントがあります：

http://dev.w3.org/html5/html-polyglot/html-polyglot.html#bib-HTML5

そしてバリデーターですら！

http://html5.validator.nu/

基本的にまだHTML5ですが、まだそこにあるため、今日ではXHTML5と呼ばれることはめったにありません（そして、おそらくもっとめったに使用されません）。

簡単に言えば、HTML5仕様に対するすべての変更は、XHTML5に対する暗黙の対応する変更でもあります。

HTML5は事実上の標準であり、標準です！標準としてXHTMLもあります。

HTML5-HTMLおよびXHTMLの語彙と関連API

W3C勧告2014年10月28日

標準のタイトルには文字列"and XHTML"が含まれているため、HTMLとXHTMLを1つの標準にマージするという W3Cの最終決定について話しているところです。この標準は、HTMLファイルをXHTMLファイルにシリアル化する方法、およびその逆を示すものです。

XHTML 部品と重要事項：

• MIMEタイプは application/xhtml+xml
• 2.2.4。XPathおよびXSLTとの相互作用
• 9. XHTML構文

理解と使用

LF Sikosがまとめたとおり

XHTML5は、HTML5のXMLシリアル化です。構文はHTML5仕様で記述されています。ただし、XHTML5はXMLのアプリケーションであるため、混乱しないでください。言い換えると、HTML5とXHTML5の語彙は同じですが、構文解析ルールが異なります。

HTML5ドキュメントも有効なXMLドキュメントである可能性があります。このマークアップは「ポリグロット」言語と呼ばれることがよくあります。同時にHTML5とXMLドキュメントであるドキュメントの重複言語です。HTML5とXHTML5のシリアル化には相互互換性があります。ただし、XHTML5の構文はより厳密です。さらに、XHTML5の一部は、処理命令など、HTML5では無効です。

したがって、厳密に言えば（そして@vaxquisによって強調されている）「XHTMLはXMLシリアル化のための単なる構文です」、DTDや他の種類のXMLスキーマはありません。

「XHTML5はXHTMLです」と言ったくない人もいます。質問は、「いつXHTMLとして使用できるか」に関するミニFAQに分割する必要があります。これはWIKIです。「誤解」がある場合は修正してください...

よくある質問

XHTML5を「2014年版のXHTML標準」として使用できますか？

「完全で汎用的なHTML5からXHTML5 / XHTML5からHTML5への変換」にはいくつかの問題があり、「個人的な選択」を行い、情報を失う必要があります。コンテキストは異なる答えになるため：

• ルーズな発言：はい。マッピングが完全で可逆的である（単純な）例がたくさんあります。

• 厳密に言えば：いいえ。以下の@vaxquisコメントおよびこのページの古い回答も参照してください。いくつかの典型的な問題：

  • https://stackoverflow.com/a/16591582/287948
  • ...さらに例を挙げて強化してください...

XSLT、XPathなどでXHTML5シリアル化を（大胆不敵です！）使用できますか？

はい、できます。フラグメントのシリアル化も。

XHTML5を検証できますか？

はい、しかしとても速く、古いDTDのより容易なことではない...と、複雑なバリデータを参照してくださいvalidator.nu

XSLTチェーンの非端末出力としてXHTML5を使用できますか？

はい、できます。できることを説明しましょう。

Cocoonなどの一部のフレームワークは、「XSLTチェーン」を使用します。HTML5およびXHTML5出力は「チェーンの最後の出力」として使用できます...もちろん、中間ステップでは、非XMLであるためHTML5は使用できませんが、XHTML5は使用できます。

ここで上記の検証の問題が再び発生します。強力な慣習がないため、「XHTML標準構造」の明確性が低下する場合があります。そのような状況では、「自分自身の慣習」に注意を払い、一貫性を保つ必要があります。

HTML5ページのDOMDocumentを使用する場合、saveXML()メソッドを使用できますか？

はい。これは、シリアル化の推奨事項が使用される典型的な状況です。XMLは有効になり、XHTML5コードは元のHTML5およびDOM状態からマップされます...しかし、上記のコメントのように、一部の構造では、一部の情報が失われる可能性があります。

はい、残念ながらXHTMLはなくなりました。

MainMaの素晴らしい答えにもう1つの理由を追加します：

XHTMLが作成されたとき、それはWebAppsによって使用され、タグスープHTMLパーサーを持たない非ブラウザソフトウェアによって理解される構造化コンテンツを提供することを意図していました。ScreenReaderの場合、XHTMLは依然として優れていますが、他の種類のソフトウェアの場合、WebServicesはそのニーズに適合し、主にXMLまたはJSONを使用します。SOAP自体には、XHTMLより単純で操作指向の独自のXMLスキーマがあります。

私が知っている限り、ブラウザと他のクライアントの両方に同じHTTPメッセージを提供するWebAppは世界に1つもありません。クライアントの好みに基づいて複数のコンテンツタイプのコンテンツの同じ表現を提供することを目的としたRESTアーキテクチャでさえ、XHTML /フィードブラウザの提供には使用されません。

たとえば、Java EEでは、Eclipseを使用して、Webサービスを提供するAxis2とともに、サーブレットを提供するユニークなwarファイルとHTMLを提供するJSPをデプロイできます。ブラウザーとWebServiceを対象とした個別のソフトウェアを開発する方が、それらすべてに対応する独自の複雑なソフトウェアを開発するよりも簡単です。

RESTが拒否される主な理由は、それについて何も知らずに、あらゆるタイプのクライアントに同じコンテンツを提供するサーバーを開発する複雑さです（そして、シンプルにすることを意図していました！）。また、XHTMLが変更されるたびにブラウザ以外のクライアントが強制的に更新されることのない安定した定義を維持するとともに、Webの高速進化のニーズに対応することも困難です。

同様に、XHTMLドキュメントを解析するブラウザー以外のクライアントを開発することは非常に困難です。たとえそれが有効であっても、ブラウザーでレンダリングされたレイアウトを構造化するためのものであり、コンテンツを保持するためのものではありません。

RESTの採用者がすでにSOAPのXMLの複雑さについて不満を言っている場合、これはブラウザー向けのXHTMLよりもはるかに単純です。

実際には、必要に応じてHTML、XMLなどを使用して、ブラウザー用のWebサイト、および非ブラウザークライアント用のあらゆる種類のWebServiceソリューションを構築します。

しかし、XHTML5を作成する必要もあると思います。XHTML 1.1（大丈夫、1.0、1.1は使用不可）はHTML5では時代遅れになりますが、HTML5の要素を受け入れ、XMLの整形式を検証するバリデーターが必要です。