仕様としては、以下のあり方が考えられています。
hn
要素に関係する要素群を、hn
要素ごと div
要素で括る (旧来の (X)HTML で最も行われてきた方法)hn
要素に関係する要素群を、まとめて divn
で括る。 hn
要素自体は divn
要素では括られない (ISO/IEC 15445 の Pre-HTML の方法)hn
要素のみで階層構造を作る (XHTML Primary の方法)section
要素の入れ子で階層構造を明示。見出しは h
要素で明示(かつて XHTML 2.0 (2022 年現在廃止)で提唱されていた方法)article
, hgroup
, section
等) を持つ要素と見出し (h1
~ h6
各要素) の組み合わせで階層構造を明治する方法 (HTML Living Standard で 2022 年現在規格化されている方法)いずれの方法を採用するにせよ、常に「終止一貫した」階層構造を作るように心がけることが、セマンティックウェブへの第一歩です。
<header> (ヘッダを構成する要素) </header> <article> <h1>見出し1</h1> <p>段落</p> <section> <h2>見出し2</h2> <p>段落</p> </section> <section> <h2>見出し2</h2> <p>段落</p> </section> </section> <footer> (フッダを構成する要素) </footer>
article
要素を用いる。section
要素はセクション明示用の汎用要素だが、見栄えのみの目的で用いるべきではない。その際には div
要素を使う。例えば hn
と div
を用いた明示方法の好例の一つに 「マーク付けノート」があります。
<div> (ヘッダを構成する要素) </div> <div> <h1>見出し1</h1> <p>段落</p> <div> <h2>見出し2</h2> <p>段落</p> </div> <div> <h2>見出し2</h2> <p>段落</p> </div> </div> <div> (フッダを構成する要素) </div>
このような一貫した構造を取っていれば、検証ツールでも容易に取り扱うことも出来ますし、文書を扱う各種プログラムにおいても、例外処理をさせる必要がないので、その分の労力を新機能開発に注ぐことが出来ます。
一方、一貫していない明示方法は、プログラムを混乱させます。検証ツールでも、例外処理を余儀なくされます。以下に、その一例を挙げておきます (旧来の (X)HTML における、 div
と見出しを混在させる手法です)。
<div> <div> <h1>見出し1</h1> <p段落</p> </div> <div> <h2>見出し2</h2> <p>段落</p> <h3>見出し3</h3> <p段落</p> </div> </div>
h1
要素 の及ぶ範囲が、どこからどこまでなのか曖昧 (通常は、h1
要素を含む div
の範囲内だけと考えられる。)h3
要素 の及ぶ範囲が、どこからどこまでなのか曖昧。中途半端な明示。上記の文書は、例えば手製のスキーマではエラーを吐きます。中途半端に div
などを使う位なら、全く使わない方がましです。少なくともスキーマやパーザは、記述が一貫してさえいれば、まともに構造を認識し、適切に処理出来ることが期待できるからです。
セマンティックウェブを視野に入れる上で大事なのは、飽くまで「構造とマーク附けが一致しており」「記述が終止一貫」しているかどうかであり、単に明示していさえすれば良いわけではありません。
私自身、 div などを用いたセクションを作成すること自体を否定するわけではないし、それがプログラム処理にとっては好都合であるのは理解出来ます。ただ一つ言いたいのは「中途半端で恣意的な明示は逆効果である」ということだけなのです。
いろいろと挙げてみました。
%divn.content
の入れ子で表すことが出来る。また、 XHTML 2.0 の如く入れ子によってセクションを定義する文書への変換も、見出し階層さえしっかり出来ていれば、簡単なスクリプトで容易に変換できる。わざわざ重いオーサリングツールを使わずとも、テキストエディタで簡潔に現すことが出来るのも、マーク附け言語の利点だと思うのです。XML は人間がテキストエディタで書かなければならないものではない。階層構造の管理などの面倒な作業は、オーサリングツールが担うべきだ。
という意見もありますが、これが昂じれば、 Word 文書の如く、「このツールがなければ編輯出来ない」という事態に陥ることもあり得るわけで。
確かに、現行の html 文書も大抵はオーサリングツールで作成しているケースが多い以上、 XML/XHTML 文書作成をツールに完全依存させるのは、一つのあり方と言えるでしょう。しかし、いざ小回りを効かせようと思うと(ちょっとカスタマイズしたいとか、文書をちょっと変更したいとか)、わざわざツールを立ち上げるよりは、テキストエディタの方が遥かに有効です。そして、可視性の高い単純な構造ならば、そのような編輯も容易に出来ます。それこそ、ツールの吐き出した階層構造を人間の目で追っかけることは、私には出来やしません。