XHTML 2.0の新機能プレビュー_HTML/Xhtml_Webページ制作

ブラウザが次世代の XHTML を処理できるようになるまで、このリッチなコンテンツ構造から利益を得ることができます。 XHTML 2 仕様はまだ完成していませんが、XHTML 1 よりも豊富な構造機能を含む多くの利点がすでにあり、XHTML 2 は以前のバージョンよりも単一のリソース公開システムの中心モデルとして機能することができます。大規模または小規模のリリースを実行します
ブラウザが次世代の XHTML を処理できるようになる前に、このリッチなコンテンツ構造から利益を得ることができます
XHTML 2 仕様はまだ完成していませんが、XHTML 1 よりもすでに多くの利点があります。 , 編集形式としての XHTML 2 は、単一のリソース公開システムの中心モデルとして、以前のバージョンよりも優れた機能を発揮します。大規模または小規模のリリースを実行しているユーザーは、ブラウザが新しいユーザー インターフェイス機能のサポートを提供するのを待つことなく、今すぐ XHTML 2 の新機能を使い始めることができます。
約 1 年前、業界標準グループから、XHTML2 がパブリッシャーにとってどのように役立つかを説明してほしいと依頼されました。現実的かどうかはわかりませんが、ニューヨークに行く費用を負担してくれるというので検討してみることにしました。
私が行った研究にはそれほど労力はかかりませんでした。 XHTML 2 は、XHTML にさらに豊富な構造を追加し、ブラウザにコンテンツを配信するだけでなく、コンテンツの作成と保存にも使用できる形式にしました。 XHTML 2 はすでに便利になっていると言うのは少し誇張しています。多くのショップはこの未完成の標準に対して非常に賢明なポリシーをいくつか持っていますが、XHTML 2 はまだ作業草案の段階にあります (詳細については、「参考文献」を参照してください)。ほとんどすべての HTML 関連標準とは異なり、XHTML 2 は、コンテンツをより豊富で複雑な構造で保存する可能性が高いため、よく知られたブラウザーがサポートする前に多くの価値を提供できます。 HTML 要素と属性。 XHTML の現状: 私たちは今どこにいるのか
W3C XHTML 1.0 標準は、HTML の XML バージョンを作成します。ブラウザーは、Web ページが整形式 XML であるかどうかにあまりこだわりませんが、Firefox 用に 1 つのことを実行し、Microsoft™ Internet Explorer 用に別のことを実行する必要があることにうんざりしている Web サイト設計者は、標準のさらなる変更に大きな価値を感じています。多くのオープン ソース CSS コレクション (Open Web Design や Open Source Web Design など、両方へのリンクについては「参考文献」を参照) には、デモンストレーション目的で XHTML 1 サンプル ファイルを使用したスタイルシートがあり、よく知られていないものもあると聞いたことがあります。形成された Web デザイナーは、自分のサイトが XHTML で構築されていると誇りを持って主張します。 Internet Explorer や Firefox がサポートする CSS 機能が増えるにつれ、これらの Web デザイナーは CSS スタイル シートにさらに多くのデザイン手法を追加し、よりシンプルで簡単な (そして再利用しやすい) XHTML を基本ドキュメントに残しています。
XHTML 1.1 (「参考文献」を参照) は新しい機能を追加しませんが、XHTML をモジュールに分割します。その価値は 2 つの側面に反映されています。まず、一部のモジュールには価値があるが、他のモジュールには価値がないことがわかった場合、そのサブセットを採用するのが簡単になる可能性があります。たとえば、Wireless Application Forum (WAP) には、携帯電話にコンテンツを配信するための標準に基本的な XHTML 構造を組み込む十分な理由がありますが、WAP ドキュメントに携帯電話で使用されるようなユーザー インターフェイス機能を組み込むことを許可したくありません。画像マッピングまたは編集モジュール機能は、小さな画面ではあまり役に立ちません。
DTD またはスキーマのモジュラー アーキテクチャのもう 1 つの利点は、ユーザーのアプリケーションに固有の新しいモジュールを簡単にプラグインできることです。既存のモジュールを選択できる機能と組み合わせることで、この機能は出版業界にメリットをもたらします。出版業界のメタデータを専門とする PRISM 標準グループは、XHTML 1.1 のサブセットを選択し、業界固有の語彙を含むいくつかの新しいモジュールを追加して、簡単に作成できるようにしました。公開ワークフローを通じてコン​​テンツを追跡します。 (PRISM の詳細については、「参考文献」を参照してください。)
XHTML 1.1 の開発を地下室の掃除にたとえることができます。おそらく、それほど多くの物を捨てる必要がなくなり、より適切に整理することで、次のことが可能になります。既存のアイテムは、新しいものを作成するための作業台を構築するためのスペースを解放することもできます。
XHTML 1.1 は 2001 年 5 月以来標準 (W3C の用語では推奨) となっています。 XHTML 2.0 に関する最新の開発は、2006 年 7 月に新しい作業草案がリリースされたことです。最終的な形に至るまでにはいくつかの段階が必要ですが、RELAX NG スキーマ (リンクについては「参考文献」を参照) が利用できるようになったので、XHTML 2 ドキュメントを作成して使用できるようになり、仕様が正式になったときにすぐに移行できるようになります。 XHTML への推奨。単純な XSLT スタイルシートは、これらのファイルをブラウザで表示できるように XHTML 1 に変換します。または、現在 XHTML 2 Working Draft (「参考文献」を参照) に含まれている CSS スタイルシートを使用してブラウザで表示することもできます (現時点では、Firefox の方が適切に機能するはずです) ）。 XHTML 2: 新機能は何ですか?
XHTML 2 は、既存の構文をクリーンアップしてより簡潔にする XHTML 1 の機能を保持しつつ、いくつかの新機能も追加しています。 10 年以上 HTML で使用されてきたフォームのより完全な後継である XForms のサポートが追加されています。 XHTML 2 には XML イベントも含まれており、これにより特定のユーザー インターフェイス操作によってトリガーされるイベントを識別できるため、JavaScript または ASP でスクリプトを記述する必要性が減ります。これらの機能は、特に主要なブラウザがサポートすると興味深いものになりますが、ブラウザが XHTML をサポートする前であっても、パブリッシャーにとっては他の機能の方が興味深いでしょう。 ​ より豊富で再利用可能な構造 ​ ​ デバイスの独立性の向上、アクセスの容易化、セマンティクスの向上 ​ ​ メタデータの追加が簡単になりました
                                                                        #p# より豊富な構造
コンテンツを XML で保存する必要がある多くのパブリッシャーは、最初からスキーマを作成するよりも、既存の標準スキーマ (W3C スキーマ、RELAX NG スキーマ、または DTD を意味します) を使用する方が良いことを知っています。 DocBook を見ると複雑すぎることがわかり、HTML または XHTML 1 を見ると単純すぎることがわかります。多くの出版社にとって、XHTML 2 は DocBook の豊富さと XHTML 1 のシンプルさのバランスが取れています。このバランスにより、コンテンツをさまざまな形式で配信するために他の形式に変換する必要があるかどうかに関係なく、XHTML 2 はコンテンツを保存するための優れた形式になります。メディアの。
リスト 1 にはサンプルの XHTML 1 ファイルが含まれており、その構造をインデント形式で示しています。
リスト 1. XHTML 1 ファイルの構造

私の Web ページ

こここれは私のウェブ ページです。

私のウェブ ページのセクション 1

これが私のウェブ ページのセクション 1です。

私の Web ページのセクション 1.1

ここに私の Web ページのサブセクションがあります。

私の Web ページのセクション 2

これが私の Web ページのセクション 2 です。

body 要素の内部を確認できます。インデントはあまりありません。これは、要素に構造があまりないためです。この文書のツリー表現では、多数の子要素を持つが孫要素のない body 要素が表示され、段落「ここは私の Web ページのサブセクションです」がメインの h1 見出し「私の Web ページ」の兄弟要素として表示されます。 。この段落がサブ段落の一部であることを示すマークアップの場所は 1 か所だけです。それに最も近い見出し h3 は、前の見出しよりも大きい数値です。 body 要素が h1 ヘッダーを Web ページの表示可能なコンテンツの残りの部分とカプセル化しない限り、container 要素は、見出しとして機能するヘッダーをそのコンテンツと組み合わせません。 p 要素を使用して、各ヘッダーとコンテンツの組み合わせをカプセル化することもできますが、p 要素は、span 要素と同様、かなり一般的なグループ化要素です。これは、いくつかの特定の段落が Web ページ内のメニュー、サイドバー、または別の視覚的プレゼンテーション要素を形成していることを示すなど、さまざまな目的に使用できるため、それが示されたコンテンツの構造単位を表していると想定することはできません。
XHTML 2 の新しいセクションと h 要素を組み合わせることで、コンテンツを再利用しやすくするより豊富な構造を作成できます。リスト 2 は、リスト 1 の body 要素と同等の XHTML 2 body 要素を示しています。
リスト 2. XHTML 2 の body 要素

My Web Page
<セクション>
私の Web ページのセクション 1 。
<セクション>
< h>私の Web ページのセクション 1.1

ここに私の Web ページのサブセクションがあります。

私のウェブ ページのセクション 2

これが私のウェブ ページのセクション 2です。

このバージョンのコードでは、「Here is a subsection」段落は最初のセクション要素の曾孫であり、「Myこのセクション要素内の Web ページ" h 要素には、メイン タイトルが表示されるはずです。
この豊富な構造の利点の 1 つは (また、XHTML 2 が単一ソース出版システムの中心的な形式として機能するのに XHTML 1 よりも適している主な理由) は、ストリーミングが容易であることです。大量の入力を処理する必要があり、処理前にそれをメモリにロードできない場合 (たとえば、CD-ROM 用のコンテンツを準備している場合)、プロセッサが各セクション要素がどこで終わるかを簡単に判断できます。 XHTML 2 ドキュメント。たとえば、「Beagle」という単語を含むすべてのタイトルを呼び出したいとします。これらの見出しを見つけるのは非常に簡単ですが、XHTML 1 でセクションがどこで終了するかを決定することはそれほど難しくありません。この XHTML の処理にストリーム ベースのインターフェイス、Xquery、XSLT のいずれを使用する場合でも、セクションの終了場所を明確に定義すると、抽出がはるかに簡単になります。
ここで、これらのセクションをビーグルに関する新しいリリースに追加するため、これらのセクションを抽出すると想像してください。抽出した各セクションには、ヘッダーとして h3 要素が含まれています。 h3 などの番号付きの XHTML 1 ヘッダーは XHTML 2 でも引き続き有効ですが、新しいリリースでこれらの要素が特別セクションのメイン セクションまたはサブセクションとして使用される場合はどうなるでしょうか?戻って、h3 要素を h2 要素または h4 要素、または新しいコンテキストでの役割を認識する要素に変更する必要があります。これらが元の文書の XHTML 2 h 要素である場合、その役割レベルは各セクションの祖先要素の番号によって示されます (たとえば、リスト 2 のセクション 1.1 h 要素には 3 つのセクション ヘッダーの祖先要素があり、「My Web Page」が含まれています) h 要素) を使用すると、それらの役割を新しいドキュメントのセクション要素のネストされた配置で示して、変更されていない新しいドキュメントに挿入できます。 CSS、XSLT、その他の XML 処理ツールと標準はすべて、ネスト レベルに基づいて同じ名前の要素を処理する方法を提供しているため、XHTML 1 ヘッダーの一部である番号を見逃すことはありません。 h2 要素と h3 要素はあるが h1 要素が存在しない、または h1 要素と h3 要素はあるが h2 要素が存在しない (X)HTML ドキュメントの数を考慮すると、適切な階層を示すためにこれらの要素を使用していない人が多すぎることが明らかになります。
XHTML 2 では、p 要素内にさらに多くの構造を含めることができます。次のようなステートメント内にサンプル コードをいくつか紹介します。
print "Hello? World?";
サンプル コードの後に​​ステートメントを続けたい場合、XHTML 1 では、ステートメントを 2 つの部分に分けたものは、2 つの異なる p 要素に配置されますが、意味的には同じステートメント内にあります。 XHTML 2 では、サンプル コード、順序なしリストや番号付きリスト、その他多くのブロック要素を p 要素内に配置できるため、マークアップがドキュメントの構造をより正確に反映できるようになります。
プレゼンテーション マークアップから構造的マークアップへの小さな一歩を踏み出すには、hr 要素の名前をセパレータに変更します。 HTML ワーキング グループは、その元の名前 (水平方向の規則を表す) が、多くの場合、構造的マークアップと表示上のマークアップの間の灰色の領域に該当することを発見しました。彼らは、アジア言語のユーザーからいくつかの垂直方向の罫線のリクエストを受け取りましたが、水平方向の区切り文字の多くは実際には罫線ではないことに気づきました (HTML ワーキング グループの議長であるスティーブン ペンバートンは、ジェイムズ ジョイスの『ユリシーズのいくつか』で次のことを指摘した声明を発表しました)さまざまなバリエーションがあります。この声明へのリンクについては「参考文献」を参照してください。これにより、hr 要素の名前を変更して、その要素が使用されていた名前をより正確に返すことができ、ステートメントの柔軟性が向上しました。
                                                                        #p# デバイスの独立性の向上、アクセスの容易化、セマンティクスの向上
これら 3 つの目標は、実際には相互に重なっています。 Web ページのコンテンツを読み上げるテキスト音声変換機能は、プラットフォーム全体に配信する必要がなく、視力の低下したユーザーでも容易に理解できる Web ページには依然として意味を持ちます。これは XHTML 2 Working Draft で言及されています:
電話、PDA、手書きパッド、テレビなど、さまざまな新しいデバイスがネットワーク上に登場します。つまり、一度作成できる設計が必要です。デバイスの種類ごとにドキュメントの新しいバージョンを作成するのではなく、デバイスごとに異なる方法でレンダリングします。
発行者は将来の価値を考慮する必要はありません。 XML が発明される前は、デバイスの独立性により、その多くが SGML に適用できました。これは、編集されたファイルに十分なデータが保存されている限り、これらのデバイスが同じコンテンツを印刷物、Web ページ、および CD-ROM で発行できるためです。コンテンツの構造的および意味論的な情報のバージョンを識別し、自動ルーチンがコンテンツをそれぞれの形式に変換できるようにします。 11 年前、競合他社が XHTML 2 を使用してコンテンツの編集バージョンを HTML として保存しようとしたとき、私の古い上司のオフィスに笑い声があふれていたのを覚えています。
XHTML 2 要素の既存のセマンティクスでは十分ではない場合は、新しい role 属性 (任意の要素に追加可能) を使用すると、要素の目的について詳しく知ることができます。 XHTML 2 仕様では、この属性に使用できる 9 つの値 (banner、note、contentinfo、search、definition、Secondary、main、seecolle、navigation) を指定しています。バナーやナビゲーションなどのロール値は明らかにプレゼンテーション指向ですが、定義やメモなどの値については、コンテンツがマルチメディア用に準備されている出版環境ではセマンティクスがより実用的です。独自の名前空間内にある限り、独自のロール値を構築することもできます。 メタデータの追加が簡単になりました
W3C RDF 標準により、URL を使用して識別できるあらゆるコンテンツにメタデータを割り当てることができます。この操作の標準 RDF/XML 構文は 1999 年に登場しましたが、その複雑さと難しさは多くの人々を怖がらせました。 XHTML 2 では、既存の HTML 属性を使用し、いくつかの新しい属性を追加することで、新しく単純な RDFa 構文を使用して、ドキュメントおよびドキュメント コンポーネントに関するメタデータを追加できます (about 属性を使用して識別できます)。リスト 3 の例の一部では、span 要素には、RDF メタデータを表すために主語、動詞、目的語の 3 つ組 (オブジェクト ID、属性名、属性値の 3 つ組の方が簡単かもしれません) を埋め込むために必要な追加情報が格納されています。
リスト 3.span 要素を使用したメタデータのエンコード

< ; span property="fb:workflowStage" content="3a"/>

死肉、わがままな息子