ただし、そもそもHTML5についていくつかの言葉を使って、私が何を導いているのかを明確にします。 私の意見では、この言語の作成者は現在の問題のみを解決しています。これは、ブラウザーに言語を実装する頃には単純に無関係になる可能性があります。 HTML5は、定義上、その場でのWeb開発の新しいトレンドを認識し、適応することができません。
しかし、XMLにはこれが可能です。 理論的には、xhtml2はまさにモジュール性と拡張性のアイデアの具体化です。 ただし、1つの問題があります。ブラウザーがサポートを開始するまで待つ必要があります。 今、私は次のことを言う自由を取ります。ブラウザは新しいマークアップ言語をまったく学習すべきではなく、開発者は学習するまで待つべきではありません。 ブラウザでできることは、xml、css、およびJavaScriptを処理することだけです。
概念は単純です。文書構造 、 プレゼンテーション、および動作を完全に分離します。 これは、それぞれxml、css、Javascriptを使用して今日できることです。 シナリオは次のとおりです。
- ブラウザー解析XMLドキュメント
- ブラウザーは、要素がどのように見えるかを示すCSSスタイルを解析し、スタイルをドキュメントに適用します
- ブラウザjsエンジンはJavascriptを実行します。これは、ページの各要素がどのように動作するかを記述します。
たとえば、スタイルがないと、ブラウザは<strong>要素の処理方法を認識しません。 また、動作を説明するjsスクリプトがないと、ユーザーがリンクをクリックしたときの動作方法がブラウザーにわかりません。 このアプローチは、おそらくDSRB-Document Structure-Representation-Behaviorと呼ばれます。
そして、実際に、上記の方法で作成されたページがMozilla、WebKit、Operaで機能することを示します（Operaには理解できない小さなヘッダーの不具合があります）-必ずソースコードを調べてください。 このアプローチの欠点は、ブラウザが自分の前にXMLドキュメントを持っていると考えている場合、JavaScriptを実行したくないということです。 このため、ブラウザーがデフォルトのスタイルと動作を定義しないように、xhtml名前空間を指定し、標準のHTML要素を避ける必要がありました。 ブラウザがXMLドキュメントのJavascriptのサポートを開始する場合、問題は解決されます。
利点は何ですか？
スマートリーダーは、今日でもHTML5をこの方法で実装できることをすでに推測しています。 同時に、ドキュメントに入力するドキュメントを追加したり、独自のDTDを作成したりできます。 Doctypeがなければ、ドキュメントは整形式のXMLになりますが、これも優れています。
将来、アイデアが根付くなら、何かに似たようなマークアップ言語がたくさんあると思います。 それらのうち2-3がおそらく最も人気があるでしょう。 しかし、最も重要なことは、DSRBを使用すると、ブラウザーですぐに動作を開始するマークアップ言語を作成できることです。