HTML文書の全體構造

文書構造の序論

ひとつのHTML 4文書は,次の三つの部分から構成されてゐます:

  1. HTMLヴァージョン情報(文書型宣言)が含まれる行
  2. 宣言的なヘッダ部分(head要素として區分される)
  3. 文書の實際の内容を含む本體(body要素かframeset要素のどちらか)

次に簡單なHTML文書の例を示します:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html>
   <head>
      <title>はじめてのHTML文書</title>
   </head>
   <body>
      <p>Hello world!</p>
   </body>
</html>

HTMLヴァージョン情報文書型宣言: document type declaration

適正なHTML文書には,どのヴァージョンであるかの文書型宣言があり,その文書で使用する文書型の名前を示します。

HTML 4.01仕樣では,趣旨によつて三つの文書型定義(DTD)が規定されてをり,著者は自身の文書に,次に提示する何れかの文書型宣言を含めねばなりません。それぞれのDTDはその性質に依つてサポートされる要素や屬性,および内容モデルが異つてゐます。

文書型宣言はその文書がDTDに照らし合せて正當な場合に限り記述できます。濫りに記してはなりません。

この覺書では,嚴格な文書型であるStrict DTDを前提に概説します。ほかの文書型に含まれる非推奬のプレゼンテーションに關する機能は概説してゐません。文書内の各要素に對してプレゼンテーションを施すには,CSSによるスタイルシートの仕組を用ゐるべきです。

文書型についての注意點

文書型定義(DTDとは,SGMLのマーク附け構成素――文書インスタンスにどのやうな要素が出現しうるのか,要素の内容にどのやうなものが含まれうるのか,要素にどのやうな屬性と値を指定しうるのか,といつた――構文を定めた宣言の集合のことです。

文書型宣言が記されない文書は,SGML應用としての適正なHTML文書ではありません。HTML仕樣ではそのやうな文書をどう扱ふのか定めてゐません。すなはち,如何なる公式な文書型にも適合しないので,どう解釋するかはUAの實裝に委ねることになります。

參考:

文書の妥當性檢證はブラウザのレンダリングを見て確認するのではなく,文法檢證サーヴィスを利用してください。User Agentは文書のマークアップに不正を發見すると何らかのエラー處理を行ふと考へられます。しかし著者は特定のエラー復元に依存してはなりません。

文書ルート: html要素

HTMLの文書インスタンスは,ひとつのルート要素(根元)から枝分かれしたツリーを形成します。そのルートに該當するのがhtml要素です。HTML文書では必ずhtml要素をルートとしてひとつ持ち,その子供としてhead要素-body要素を順にひとつづゝ内包します。

html要素はタグに據つて明示せずともその存在は明らかなので,HTML 4では開始タグと終了タグは共に省略可能です。ソース文書内にhtml要素の開始タグや終了タグが存在しなくとも,適合User Agentはその存在を推量して,文書ツリーを正しく組立てます。

しかしhtml要素には國際化としてlang屬性の指定が推奬されるので,一般には明示して置きます。その文書の基本言語が日本語であれば lang="ja",英語であれば lang="en" と指定します。UAはこの言語情報を何らかの處理に役立てるかもしれません。

html要素は單なる文書ツリーのルートに過ぎません。明示する必然性は薄いので,HTML 4ではタグの省略を許容します。html要素はその役割として「HTML文書であることの宣言」を意味しません。HTML文書であるかは,そのリソースの要求に對して返されるHTTP應答ヘッダで判斷されます。また,どのHTMLヴァージョンであるかは,SGMLのマークアップ言語として必須である文書型宣言で明らかになります。

文書のヘッダ

head要素

head要素はその文書についての情報を記述します。この中身には必ず一つのtitle要素があらねばなりません。そのほか,文書の本文内容にはならない,文書自身に關する情報(メタデータ)なども指定できます。一般的なUAではhead要素に現れる要素について本文として扱ふことはなく,カンヴァスにレンダリングしません。その代りに他のメカニズムを通じて,head要素の情報をユーザに提供するかもしれません。

HTML 4ではマーク附けで明示せずともhead要素の範圍が明確なら,この要素の開始タグと終了タグは共に省略可能です。ソース文書内にhead要素の開始タグや終了タグが存在しなくとも,適合UAはその存在を推量して,文書ツリーを正しく組立てます。

メタデータ: meta要素

meta要素ではメタデータ――文書の本文内容ではないその文書自身に關する情報――を指定します。

次のmeta宣言は,當該文書の文字符號化方法が "Shift_JIS" であると傳へてゐます:

<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">

次のmeta宣言は,デフォルト-スタイルシート言語とデフォルト-スクリプト言語を傳へてゐます:

<meta http-equiv="Content-Style-Type" content="text/css">
<meta http-equiv="Content-Script-Type" content="text/javascript">

本來,User Agentに文書の文字符號化方法の情報を提供する最も直截な方法は,サーヴァのHTTP應答ヘッダのContent-Typeフィールドでcharsetパラメータを使ふことです。同樣にデフォルト言語なども本來サーヴァ側で設定します。しかし多くの著者はサーヴァ管理の權限を與へられてゐない事でせう。そのやうな著者についてはUser Agentにこれらの情報を傳へるために,上記のmeta宣言を用ゐることができます。

著者は文書で實際に使用してゐる文字符號化と,meta宣言による指定とが喰ひ違はないやう注意してください。

そのほかUser Agentに對して「著者の名前」,「文書の概要」,「文書に關するキーワード」なども提供できます:

<meta name="author" content="Katsu">
<meta name="description"
    content="HTML文書の全體構造――文書型宣言,ルート要素,ヘッダ情報と文書本體。">
<meta name="keywords" content="HTML,meta,タイトル,見出し,address,id屬性,class屬性">

檢索エンジンのロボットなど,文書の情報を拾ひ集めるUAはこれらメタ情報をデータベースに登録するかもしれません。そして檢索結果のサマリーとして提示するかもしれません。ウェブブラウザでも "お氣に入り" や "ブックマーク" 情報の一部として記録するでせう。

これらのmeta宣言はhead要素の中身において,出來るかぎり頭のはうに記述する必要があります。たとへば「文字符號化方法」を設定してゐるmeta宣言よりも前に "非ASCII文字列"――title要素に記される "かな" や "漢字" など――を表してはなりません。

文書タイトル: title要素

HTML 4文書では,head要素の中身に必ず一つのtitle要素があらねばなりません。當然,中身が何もない空のタイトルでもいけません。title要素の中身にはあらゆる文字(文字參照やアクセント附き文字など)を含めて構ひませんが,コメント宣言も含めて,ほかのマークアップが現れてはなりません。この要素はHTML 4文書において唯ひとつ省略することが許されない,最も重要な要素であると捉へてください。

たとへば圖書館や書店の棚に竝べられた "本" の背表紙にタイトルのない物があつたら,あなたはそれに手を伸ばすでせうか? どんなに有益な本であつてもその存在に氣附いて貰へなければ意味がありません。これはウェブ上のリソースにおいても同樣なのです。

(註:文書タイトルが不明である場合,UAは代りにURLを示したりしますが,それはエラー處理の結果に過ぎません。)

この文書タイトルは樣々に利用されてゐます: たとへば視覺系ブラウザなら當然タイトルバーに示されますし,音声ブラウザなら合成音聲により眞つ先に話されるでせう。文書の全體像を把握するのが困難な非視覺系メディアでは,タイトルは特に重要と言へます。

他にも,ブックマーク登録時の初期名稱や,履歴情報として保持されたり,檢索結果の一覽にも用ゐられます。

また,あなたの文書を何處かで紹介したいと考へる人もゐるでせう。つまりその時にうまく紹介できないやうな役に立たないタイトルではいけません。言ひ換へれるならば,讀者がタイトルだけを見てアクセスすべきかどうか判斷できる材料になるやう,工夫すべきなのです。

文書タイトルは必須――重要な事から簡潔に

著者は短すぎず,長すぎず,文書の内容を收斂させた簡潔な文書タイトルを提供すべきです。また,サイトの文脈をまだ知らないユーザでも各文書の要約が個別に理解できる樣にすべきです; たとへば單なる『概説』ではなく,『HTML 4.01の概説』とするなど。

title要素に記す内容の順序は,始めに「その文書自身の名前」を記して,次いで「屬するリソース群の名前」を連結するのが好ましいでせう。なぜなら,GUIや檢索結果のタイトル欄といふのはその面積が屡々制限されて,後ろのはうの内容は省かれて仕舞ふからです。肝腎な主題が見えなくては困ります。また音聲ブラウザでは毎囘リソース群の名前から話し始められると煩しいので,これを避ける意圖もあるのです。

フレームセット文書に據つて,あるいは行内フレーム(iframe要素)に據つて,結び附けられた各文書にも,適切な文書タイトルが必要です。User Agentおよびユーザは,フレームとしてではなく,各文書に直接アクセスするかもしれません。つまり,各文書が獨立したひとつのリソースとしても識別できるやうにすべきです。また非視覺環境の讀者は各フレームの概觀をひと目では把握できないので,文書タイトルは肝要です。

文書本文

body要素

body要素には,User Agentのカンヴァスにレンダリングされる實際の本文内容を記述します。たとへば視覺系ブラウザでは,テキスト,畫像,色,圖などの視覺的な整形構造が現れるカンヴァスを持ち,一般にはそのカンヴァスを表示域(viewport)に出力するでせう。一方,音聲メディアのUser Agentでは,一次元の時間の流れに伴つて(合成音聲で)話される,音聲空間としてのカンヴァスを持つと考へられます。

HTML 4ではマーク附けで明示せずともbody要素の範圍が明確なら,この要素の開始タグと終了タグは共に省略可能です。ソース文書内にbody要素の開始タグや終了タグが存在しなくとも,適合UAはその存在を推量して,文書ツリーを正しく組立てます。

ブロックレヴェル要素とインライン要素

HTMLの要素はふたつの性質で大別されます: それはブロックレヴェル要素と呼ばれるbody要素のぢかに含まれうる骨骼を成すものと,その行内で斷片的に插入されるインライン要素です。すなはちブロックレヴェル要素のはうがより大きな構造を成します。

ブロックレヴェル要素とは,謂はば『ひと固まりの完結した思想』であり,大きな構造を成します。視覺系UAはこれらの前後で行を分斷し,表示域の幅に應じた矩形ブロックとしてレンダリングするでせう。この見た目は飽くまで表現現象であり,本質ではありません。

一方のインライン要素とは,謂はば『行内での斷片的な意圖』であり,小さな構造を成します。これらは常にブロックレヴェル要素の行内に分散して插入されます。もしテキスト内容が單一行で收り切らないなら,複數の行を跨いで分割してレンダリングされます。

ブロックレヴェル要素型を擧げるとh1〜h6(見出し),p(パラグラフ),ul,ol,dl(リスト),blockquote(ブロックレヴェルの引用),address(問ひ合せ),pre(整形濟みテキスト),div(グループ化)などがあります。インライン要素型にはem,dfn,a,imgなどがあります。

見出し: h1, h2, h3, h4, h5, h6要素(Headings)

内容の長い文書は,しばしば樣々な "章" に分けられ,章は副次的な主題を持ち,それは更に "節" に分割され,最終的に "パラグラフ" へと到逹するやうに階層構造を成すものです。そして,これらの情報の意味的な "かたまり" が文書の概觀を作り上げてゐます。

このやうな見出しセクションの "かたまり" は,HTML文書では "見出し要素(h1〜h6)" に據つて開始されるべきです。ただしHTML 4の見出し構造では,h1〜h6要素に據つてそのセクションの開始を示すだけで,そのセクション自體の範圍を明示する仕組が無いことに注意してください。これはHTMLといふ言語が,なるべく複雜な階層構造を避けるやう,誰にでも簡單にマーク附けできるやう,設計されてゐるためです。

h1〜h6要素の中身には,そのセクションの話題をインライン内容(文字データやインライン要素)で簡潔に示します。

見出しレヴェルとその階層

文書の見出しは,文書の構造から見て最上位のh1要素から始り,h2要素,h3要素,h4要素……といふ順に最低位のh6要素まで,セクションの階層に應じてマーク附けします。見出しの數字は,見出しの階層レヴェルであつて,文字の大きさではありません

見出しレヴェルを飛ばすのは惡しき習慣です――たとへばh2要素からh4要素へ,といふ具合に。これはHTML 4では文法違反ではありません(より嚴格なISO-HTMLではエラーです)が,論理的に不自然ですし,見出しレヴェルを頼りにするユーザを混亂させます。

また,一つのHTML文書は一つの完結したリソースであるべきで,文書の見出しはh1要素から始めるべきです(大きな話題を一つの文書で扱ひ,文書を分割しない)。h1要素にはリソース群の名稱ではなく,その文書自身の要約を記述すべきです(ブログや掲示板などは例外)

文書本文の末尾にフッタのセクションを設けるなら,そこにもフッタの開始となる見出し要素が必要です。さうでないと構造上,そのフッタは直前の見出しセクションの内部に收容されてしまひます。フッタの見出しを隱したいなら,CSSで display: none を適用します。

視覺系ブラウザは慣例として,より上位の見出しを大きく,より低位の見出しを小さくレンダリングします。しかし必ずしも,さうなるとは限りません。見出しの表現および利用方法は,User Agentが對象とするメディアに依つて樣々なのであり,あるウェブブラウザでのデフォルトの "見た目" に左右されて,不適切に濫用してはなりません。見出しの外觀は,著者スタイルシートの指定に據つて,どのやうにでも變更できます。

見出しの拾ひ讀み/編輯

ユーザは見出しを利用して,文書を拾ひ讀みするかもしれません。たとへばあるUser Agentでは,見出し要素から "目次" を自動生成して,目的の位置にすばやく移動できるかもしれません。また,キー操作などで前後の見出し位置へすばやく移動できるかもしれません。

このやうな機能は,文書を限られた狹い表示範圍でしか見れない,もしくは全く見れない人々にとつて特に有益です――たとへば合成音聲による讀み上げ,弱視もしくは畫面から遠いための擴大表示,狹い畫面解像度での利用者,視野狹窄の障礙を持つ人など。

見出し要素は,ユーザだけでなく著者に役立たせることも可能です。たとへばテキストエディタに依つては,見出し要素を自動收集して,その編輯行に移動できるメニューを用意するかもしれません。あるいは,文書内もしくは目次文書で用ゐるための目次リストのマークアップを自動生成する機能が提供されるかもしれません。著者自身がマクロに據り,このやうな見出しを役立たせる機能を獨自に實裝することも可能です。

以下に,見出し要素を活用してゐるソフトウェアまたは擴張機能をいくつか紹介します:

iCab(Mac用)
コンテキストメニューから「ページの概観」として,見出しを階層的にリストアップしてくれる。
Opera
S/Wキーによつて,現在の表示範圍で最も近い前後の見出し位置に移動できる。
IBM ホームページ・リーダー(音聲ブラウザ)
「見出し読みモード」によつて,文書内の見出し要素だけを順番に讀んで行くことができる。このとき,見出しレヴェルも合せて讀み上げられるので,文書の階層も把握可能になつてゐる。(參考:音声ブラウザと見出し ごく簡単なHTMLの説明
Firefox
見出しアウトライン for Firefox(拙作)……Bookmarkletで見出し一覽。
コンテキストメニュー拡張(piro氏作)……iCabとOperaの機能を再現できる。
Camino べんりセット(ありみか氏作)……「見出し一覧」の機能が含まれる。
WinIE
IEコンテキストメニューセット(さつぱり氏作)……「見出しツリー」の機能が含まれる。
MacIE
MacIE5 べんりセット(ありみか氏作)……「見出し一覧シート」の機能が含まれる。
秀丸エディタ
見出しツリー生成マクロ(piro氏作)……目次リストを生成してクリップボードに格納できる。
見出し位置へ移動するマクロ(拙作)……見出し要素の編輯行に移動できる(その畫像)。
ez-HTML
スペシャルサイドバーの「アウトライン解析」によつて,見出し一覽/移動ができる。
xyzzy
GNU emacs editor likeな高度なテキストエディタです。
outline-tree2およびtreeviewライブラリで,見出しアウトラインを表示できます(その畫像)。
li要素やdt要素も階層に插入されます。見出しセクションの上/下を入替へたりも出來ます。

問ひ合せ先: address要素

address要素は,文書全體,または文書内の主要部分に對して,問ひ合せ情報(著者名・メールアドレスなど)を提供する際に用ゐられます。問ひ合せ以外にも "作成日時","改定日時","著作權情報" なども併せて記されます。一般慣習では,文書本文の冒頭か末尾にフッタのセクションを設けて,その範圍の中で利用されます。しかし出現囘數は制限されないので,その他のセクションで用ゐても構ひません。

address要素の中身には,文字データに加へてインライン要素を含められますが,ブロックレヴェル要素は一切含められません。したがつて,何らかの意圖でテキストを複數行に分けて記述したい場合には,br要素を用ゐて強制的に行區切りを生じさせる事になります。

ウェブサイトを構成する各文書には "著者情報","作成日","改定日" の情報を明確に記して置くべきです。たとひハイパーリンクの繋がりで一つのサイトに見えてゐても,各文書はひとつのURIが與へられた獨立したリソースである事に變りありません。ひと綴りの書物では奧附の一頁に記して置けば濟みますが,ウェブ文書では銘々が完結した單一のリソースとして見做されので,各文書ごとに著作情報が必要なのです。

しかし,著作情報をaddress要素として示すかどうかは意見が分かれるやうで,address要素を懷疑的に捉へる人々もゐます。彼らは,著者情報は文書の本文として示せずとも,ヘッダ情報としてmeta要素やlink要素で示すことで充分に役割を果たす,と云ふのです。

要素識別子: id屬性とclass屬性

HTMLのほぼすべての要素は,汎用屬性としてid屬性とclass屬性を指定できるやう,設計されてゐます:

id="name" [CS]
class="cdata-list" [CS]

(補足:[CS]――大文字と小文字を區別することを意味する。ただし,大文字と小文字が異るだけのid屬性の名前は,一意性に缺けるので,同一文書中で同時に出現してはならない。たとへば "toc" と "ToC" といふid屬性の名前なら,この兩者は同一文書中で同時に出現できない。)

HTMLにおいてid屬性は次のやうな役割を果たします:

HTMLにおいてclass屬性は次のやうな役割を果たします:

これらの屬性は,要素を識別するための手段として樣々に利用され得ます。著者は自身によつて,あるいはユーザによつて,それぞれの識別子がどのやうに利用されうるのか,考慮する必要があります。つまりあとで變更せずに濟むやうな普遍的な名前を檢討すべきです。

見た目に依存しない名前

idおよびclass屬性には,視覺的なスタイルに關聯した名前を附けるべきではありません。たとへば色,テキスト效果,フォント,餘白,枠,配置,寸法に關聯するもの等です。このやうな名前を用ゐてしまふとウェブデザインが恣意的になり,保守性を落とします。著者のスタイル構想が變化してしまふと,必然的にマーク附けが破綻してしまふからです。つまり,スタイルの再設計に據つて,文書の再構築を強ひられるのです。

名前附けは,視覺的な發想によるものではなく,その要素が持つべき本質的な事柄をあらはす名稱を用ゐるべきです。たとへばabstract,article,sectionなどの語を用ゐてゐれば,後でスタイルシートを再設計する際にも,文書のマーク附けを變更せずに濟みます。

また,或る文書に對應するスタイルシートは,一對一に限られず,一對多であつても良い點に,注目すべきです。たとへば著者は,HTML 4仕樣で定められてゐる優先・代替スタイルシートの仕組を用ゐると,選擇可能な多種類のスタイルシートをユーザに提供できます。

id屬性か? class屬性か?

"class" は複數の要素を『同一の分類』として纏め,"id" は單一の要素を『固有の存在』として識別します。

文書内で要素を一囘だけ識別すれば良いから,といふ理由だけでid屬性を指定すべきではありません。その文書内で "一意に識別する必然性" はあるのか,"本當に唯一無二の存在" なのか,"他文書にも出現しうる分類" ではないのか,よく檢討すべきです。

その要素が固有の存在であり,何かの分類にも屬するなら,id屬性とclass屬性を併用しても構ひません。

著者は,分類であるclass屬性の役割と混同して,id屬性の名前を文書内で何度も重複させてはなりません。たとへばid屬性がハイパーリンクの終點アンカーとして利用される場合,User Agentは複數ある同じアンカー名から一體どれを選べば好いといふのでせうか。User Agentはこのやうなエラー状態を何かしらの方法で囘避すると考へられますが,著者とユーザの雙方は,特定のエラー復元に依存してはなりません。

グループ化: div要素とspan要素

これらは,前述のidまたはclass屬性と併用して,文書に構造を附加するメカニズム一般として提供されます。

それぞれインラインであるか(span),ブロックレヴェルであるか(div)は定められますが,そのほかのレンダリング效果は現れません。それゆゑに著者は,これらの要素に對してスタイルシートやlang屬性などを指定して,文書を自身の要求や趣向に應じさせられます。

ただし,divやspanばかりに依存してはなりません。HTMLはユニヴァーサルな意味や構造をマークアップで明らかにし,あらゆるUser Agentが理解可能であるやうに設計すべきものです。スタイルシートの下地として,HTML文書が存在してゐるのではありません

これらの要素は,謂はば『匿名の要素』であり,いかなる意味論を持ちません。これらにclassやidを割り當てたしても,それに據つて意味が生じる訣ではありません。idまたはclass屬性の名前に意味があるとしても,その意味を直接的に理解できるのは人間のみです。

div要素は,何らかの關聯性を持つた "ブロックレヴェル要素の集まり" として用ゐるべきです。すなはち,div要素のぢかはブロックレヴェル要素だけで構成されるべきです。div要素のぢかに斷片的な情報である筈のインライン内容を存在させるのは,好ましくありません。

構造として機能するブロック

id屬性は,一聯の文書群で統一の "骨骼" として意圖する,div要素(もしくはその他のブロックレヴェル要素)のセクションを補足するために,しばしば利用されます。よくある例としては,body要素のぢかに現れる大きな骨骼構造を意圖して,ヘッダ部(header),ナヴィゲーション部(navigation),主内容(main),フッタ部(footer)などのやうなグループを構築する,といふ設計方法がしばしば見られます。

一方のclass屬性は,一聯の文書群で機能するブロックの "分類" として利用できます。たとへば,參考文獻を提示するリストは一つの文書内で頻繁に用ゐられるかもしれません。そのやうな機能ブロックは名前を附けて,分類として纏めておくと便利でせう。

ただし,意味や構造をあらはすブロックレヴェル要素型を用ゐずに,div要素ばかりに依存してはいけません。HTMLで豫め用意されてゐる要素型――見出し(h1〜h6),パラグラフ(p),箇條書き(ul,ol),定義リスト(dl),引用ブロック(blockquote)など――を最大限に活用すべきです。これらの要素はHTMLのユニヴァーサルな基本構造として,User Agentの對象メディアに合致した方法で適切に表現されます。