web-dev-qa-db-ja.com

XHTML5は死んでいますか、それともHTML5の同義語ですか？

では、XHTML5はどうなったのでしょうか。

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

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

html5xhtml
93
W3C

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

  • XHTMLに本当に興味を持った人はほとんどいません。ほとんどのウェブサイトはプレーンHTMLで書かれていました。

  • さらに、XHTMLの概要とその使用方法を理解している人はほとんどいません。 XHTMLを提供するふりをしたWebサイトが多すぎて、Content-Type: application/xhtml+xmlではなく、誤ったヘッダーが使用されていました。

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

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

  • HTML 5コードを書くことは、タグをすべて混ぜることを意味しません。 XMLとXHTMLに情熱を傾けている場合でも、XMLに非常に近いHTML 5コードを書くことができます。

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

2014年10月の仕様は XHTML構文 について言及しています。現時点では、新しいXHTMLlanguage（notsyntax）などがあるかどうかは不明ですが、つまり、XHTMLの位置づけや、主流のブラウザーによる新しいXHTML標準の採用などです。

78
Arseni Mourzenko

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

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

...

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

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

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

そしてバリデーターさえ！

http://html5.validator.nu/

基本的にはまだHTML5ですが、まだ存在しているため、最近ではXHTML5と呼ばれることはほとんどありません（使用されることもほとんどありません）。

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

33
user88637

HTML5はde factoおよびde jure標準です！ XHTMLも標準で用意されています。

HTML5-HTMLとXHTMLの語彙と関連API

W3C勧告2014年10月28日

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

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です。「誤解」がある場合は修正してください...

FAQ

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

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

  • ゆるい話：はい。マッピングが完璧で可逆的である（単純な）例はたくさんあります。

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

XSLTやXPathなどでXHTML5のシリアル化を使用することはできますか？

はい、できます。フラグメントをシリアライズすることさえ。

XHTML5を検証できますか？

はい、しかし古いDTDほど速くて簡単ではありません... validator.n のような複雑なバリデーターを参照してください

XHTML5をXSLTチェーンの非ターミナル出力として使用できますか？

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

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

上記のvalidationの問題がここに再現されます。強い規則がないため、「XHTML標準構造」の明快さが失われることがあります。そのような状況では、「自分の慣習」に注意を払い、一貫している必要があります。

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

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

10
Peter Krauss

はい、残念ながらXHTMLはなくなっています。

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

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

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

Java EEの例では、Eclipseを使用して、サーブレットとJSPを保持する独自のwarファイルを配備し、Axis2とともにWebServiceを提供します。ブラウザ向けの個別のソフトウェアを簡単に開発できますとWebServiceよりも、それらすべてに対応する独自の複雑なソフトウェアがあります。

REST=拒否される主な理由は、どのタイプのクライアントにも同じコンテンツを提供するサーバーについて、何も知らずにサーバーを開発することの複雑さ（そして単純にすることを意図したもの）です。また、XHTMLが変更されるたびにブラウザー以外のクライアントを強制的に更新しない安定した定義を維持するとともに、Webの急速な進化の必要性に対処することも困難です。たとえば、多くの異なるモジュールによって構築されたとき、XHTMLを有効に保つことです。

同様に、XHTMLドキュメントを解析する非ブラウザークライアントを開発することは、たとえそれが有効であっても、ブラウザーレンダリングレイアウトを構成することを意図しており、コンテンツを保持することを意図していないため、非常に困難です。

REST採用者がSOAPのXMLの複雑さについて不満を言っている場合は、ブラウザー向けのXHTMLよりもはるかに単純ですが、複数のクライアントタイプ、サーバー、クライアント側でXHTMLを処理するのがどれほど難しいか想像してみてください。

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

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

9
Hikari