現在の HTML5 ドキュメントを多言語 HTML5 ドキュメントに変換することを検討しています。たとえtext/html.
HTML5 のみの空間で、これを賢明な選択とはならないような特にスリリングなものはありますか?
第二に、多言語ドキュメントを検証する方法について仕様が少し曖昧です。基本は次のとおりだと思います。
しかし、私が見逃している他のルールはありますか?
第三に、それは多言語であるためapplication/xhtml+xml、サポートしているブラウザとサポートしていtext/htmlないブラウザにサービスを提供する際の注意事項を知っている人はいますか?
編集:少し実験した後、エンティティ が XHTML5 (DTD なし) で壊れていることがわかりました。この XML パーサーは両刃の剣のようなものです。3 番目の質問には既に答えていると思います。
HTML5ポリグロットドキュメントの作成方法の定義に関する作業は現在進行中ですが、初期のドラフトについてはhttp://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.htmlを参照してください。 。確かにそれは可能ですが、それはかなりのコーディング規律を必要とし、あなたはそれが努力する価値があるかどうかを決定する必要があります。HTML4.01 / XHTML1.0ポリグロットドキュメントを作成しますが、XMLの整形式性を保証し、HTMLの非void要素および有効なXML文字との互換性を確保するための特殊なコードを備えたXMLツールチェーンを使用して作成します。直接のハンドコーディングは非常に難しいでしょう。
HTML5の現在の既知の問題の1つは、iframe要素のsrcdoc属性です。属性の値にはマークアップが含まれているため、特定の文字をエスケープする必要があります。HTML5ドラフト仕様では、HTMLシリアル化でこれを行う方法について説明していますが、（最後に調べたときは）XHTMLシリアル化でこれを行う方法については説明していません。
私はパーティーに遅れましたが、5年経った今でも質問は関連しています. 一方で、すべてのタグを閉じることは、私にとって非常に魅力的です。それを読んでいる人のために、編集しやすくするために、大正義のために。OTOH、ポリグロット仕様の悲惨な詳細を見る — http://www.sitepoint.com/have-you-considered-polyglot-markup/の最後に便利な要約があります — 私には理解できないことは明らかです手で大丈夫。
https://developer.mozilla.org/en/docs/Writing_JavaScript_for_XHTMLも、XHTML が失敗した理由について興味深い光を当てています。XML MIME タイプを使用するという選択そのものが、実行時にさまざまな副作用をもたらします。今では、適切な JS コードがこれらを処理することは日常的になっているはずですが (たとえば、比較する前にタグ名を常に小文字にします)、私はそのすべてを望んでいません。現状のままでテストするのに十分なクロスブラウザーの問題があります。ありがとうございます。
だから私は便利な中間の方法があると思います：
今のところ としてのみ機能しtext/htmlます。HTML モードと XML モードの両方で、実際にはまったく同じ DOM として解析され、実行時の動作が同じになるのではないかと心配する必要はありません。
整形式の XMLとして解析されるように努力してください。読者や編集者を助け、自分のドキュメントで XML パーサーを使用できるようにします。
残念ながら、多言語ツールが存在しないことはめったにありません — HTML 要件も満たす方法で XML をシリアライズすることさえ困難です...
簡単に言えば、常に void タグを自分で閉じ ( <hr/>)、非 void タグを個別に閉じます ( <script ...></script>)。
selected="selected"頭を悩ませる必要はありません: 小文字のタグと attr を使用します (一部の SVG を除きますが、外国のコンテンツは XML ルールを使用しますselected)。
インライン<script>であり<style>、最も厄介です。&XML 解析を中断せずにor <inside を使用することはできません。私は欲しい：
<script>/*<![CDATA[*/
foo < bar && bar < baz;
/*]]>*/</script>
...それだけです！XML名前空間を気にしないか、テーブルのHTMLの暗黙のDOMに一致させると、ルールの約半分が失われます:-)
多言語性をスキップして、XHTML の作成に直接取りかかることができるようになるまでしばらくお待ちください。利点は、タグを閉じる制限を忘れることができ、XML ツールで直接使用および生成できることです。確かに、xml の名前空間などを無視すると、切り替えが難しくなりますが、今後は、既存のドキュメントを変換するよりも、新しいドキュメントを作成する方が多いと思います。
実際、私が今、その未来に生きることを妨げているものは何なのか、完全にはわかりません。IE8だけですか？また、全か無かのエラー処理についても少し心配しています。将来の HTML 仕様で、HTML と XML のギャップを縮小する方法が見つかることを少し期待しています。たとえば、HTML エラー処理を維持しながら、<hr></hr>ブラウザーが HTML を受け入れられるようにするなどです。<script .../>
また、ツール。ポリグロット マークアップにシリアル化できる多くの言語のライブラリがあれば、プログラムでそれを生成できるようになります。HTML5 <-> polyglot <-> XHTML5 を検証および変換するためのツールがあると役立ちます。そうでなければ、それはかなり運命づけられています。
HTML と XHTML の違いに関する W3C のドキュメントが完成していないことを考えると、ポリグロットを試すのに時間をかける価値はおそらくありません。とにかくまだ....あと数年待ってください。
いずれにせよ、特定の目的のために HTML を XML として解析することを積極的に計画している非常に狭い状況でのみ、XML 準拠に余分な時間を費やす必要があります。純粋に Web ブラウザーで使用するためにこれを行う利点はありません。欠点があるだけです。
あなたはすべきですか？はい。しかし、最初にいくつかの点について説明します。
ヘッダーを送信するContent-Type: application/xhtml+xmlということは、それが XML パーサーを通過する必要があることを意味するだけであり、私が知る限り、HTML5 のすべての利点をまだ持っています。
XML で定義されていないAbout 。XML で定義されている唯一の文字エンティティ参照は、lt、gt、apos、quot、および amp です。それ以外の場合は、数値文字参照を使用する必要があります。nbsp のコードは or です。個人的には 16 進数を好みます。これは、Unicode コード ポイントが 16 進数 (U+00A0) で表されるためです。
ヘッダーを送信すると、閉じられていないタグ、不要な終了タグ、タグとして解釈される可能性のあるテキストなど、基本的にサイトの外観や機能を損なう可能性のあるマークアップの問題をすばやく見つけることができるため、テストに役立ちます。
私の意見では、最も重要なのは、ユーザー入力を許可していて解析に失敗した場合、それは通常、ユーザーのデータをエスケープせず、脆弱性にさらされていることを意味します. HTML として解析されると、誰かがスクリプトを挿入してユーザーに嫌がらせをしたり、データを盗んだりするまで、問題に気付かない可能性があります。
このページは、多言語マークアップとは何かを説明するのに非常に適しています: https://blog.whatwg.org/xhtml5-in-a-nutshell
このウィキには、W3Cドキュメントにはない情報がいくつかあります：http ：//wiki.whatwg.org/wiki/HTML_vs._XHTML
これは非常に難しいことのように聞こえます。XHTML の欠点の 1 つは、XML と従来の HTML の競合する要求の間でうまく舵を取ることができなかったことです。
HTML5 を作成して検証に成功すれば、誰もが必要とするほど整然とした有効なドキュメントが得られると思います。