HTML覺書ナヴィゲーションを讀み飛ばす。要素のどちらか)空白類やコメント宣言は,上記三部分の前後どちらにも出現できます。2番目と3番目の部分は,ルートであるhtml要素の内容に含まれます。declaration適正なHTML文書には,どのヴァージョンであるかの文書型宣言があり,その文書で使用する文書型の名前を示します。4.01仕樣では,趣旨によつて三つの文書型定義(DTD)が規定されてをり,著者は自身の文書に,次に提示する何れかの文書型宣言を含めねばなりません。それぞれのDTDはその性質に依つてサポートされる要素や屬性,および内容モデルが異つてゐます。本來の理想的な文書型です。3.2で妥協的に導入されたプレゼンテーション目的の要素や屬性のうち,非推奬(deprecated)のものを含みません。推奬されない要素や屬性(その多くは視覺的表現に關するもの)を含む,嚴格な文書型に移行するまでの猶豫として存在する,妥協的な文書型です。DTDのすべてに加へて,文書を複數の表示域(フレーム)で提供するためのフレームセット文書を記述するのに用ゐる要素を加へたものです。"http://www.w3.org/TR/REC-html40/frameset.dtd">文書型宣言はその文書がDTDに照らし合せて正當な場合に限り記述できます。濫りに記してはなりません。DTDを前提に概説します。ほかの文書型に含まれる非推奬のプレゼンテーションに關する機能は概説してゐません。文書内の各要素に對してプレゼンテーションを施すには,CSSによるスタイルシートの仕組を用ゐるべきです。文書型定義(DTD)とは,SGMLのマーク附け構成素——文書インスタンスにどのやうな要素が出現しうるのか,要素の内容にどのやうなものが含まれうるのか,要素にどのやうな屬性と値を指定しうるのか,といつた——構文を定めた宣言の集合のことです。文書型宣言が記されない文書は,SGML應用としての適正なHTML文書ではありません。HTML仕樣ではそのやうな文書をどう扱ふのか定めてゐません。如何なる公式な文書型にも適合しないので,どう解釋するかはUAの實裝に委ねることになります。Personnel文書の妥當性檢證はブラウザのレンダリングを見て確認するのではなく,文法檢證サーヴィスを利用してください。Agentは文書のマークアップに不正を發見すると何らかのエラー處理を行ふと考へられます。著者は特定のエラー復元に依存してはなりません。html要素HTMLの文書インスタンスは,ひとつのルート要素(根元)から枝分かれしたツリーを形成します。そのルートに該當するのがhtml要素です。HTML文書では必ずhtml要素をルートとしてひとつ持ち,その子供としてhead要素-body要素を順にひとつづゝ内包します。4では開始タグと終了タグは共に省略可能です。Agentはその存在を推量して,文書ツリーを正しく組立てます。html要素には國際化としてlang屬性の指定が推奬されるので,一般には明示して置きます。UAはこの言語情報を何らかの處理に役立てるかもしれません。html要素は單なる文書ツリーのルートに過ぎません。4ではタグの省略を許容します。html要素はその役割として「HTML文書であることの宣言」を意味しません。HTML文書であるかは,そのリソースの要求に對して返されるHTTP應答ヘッダで判斷されます。どのHTMLヴァージョンであるかは,SGMLのマークアップ言語として必須である文書型宣言で明らかになります。文書のヘッダhead要素head要素はその文書についての情報を記述します。この中身には必ず一つのtitle要素があらねばなりません。そのほか,文書の本文内容にはならない,文書自身に關する情報(メタデータ)なども指定できます。一般的なUAではhead要素に現れる要素について本文として扱ふことはなく,カンヴァスにレンダリングしません。その代りに他のメカニズムを通じて,head要素の情報をユーザに提供するかもしれません。4ではマーク附けで明示せずともhead要素の範圍が明確なら,この要素の開始タグと終了タグは共に省略可能です。ソース文書内にhead要素の開始タグや終了タグが存在しなくとも,適合UAはその存在を推量して,文書ツリーを正しく組立てます。meta要素meta要素ではメタデータ——文書の本文内容ではないその文書自身に關する情報——を指定します。meta要素は空要素であり,内容を持ちません。4では終了タグがありません。據りマーク附けします。Agentに文書の文字符號化方法の情報を提供する最も直截な方法は,サーヴァのHTTP應答ヘッダのContent-Typeフィールドでcharsetパラメータを使ふことです。同樣にデフォルト言語なども本來サーヴァ側で設定します。多くの著者はサーヴァ管理の權限を與へられてゐない事でせう。Agentにこれらの情報を傳へるために,上記のmeta宣言を用ゐることができます。Cafe著者は文書で實際に使用してゐる文字符號化と,meta宣言による指定とが喰ひ違はないやう注意してください。ルート要素,ヘッダ情報と文書本體。content="HTML,meta,タイトル,見出し,address,id屬性,class屬性">檢索エンジンのロボットなど,文書の情報を拾ひ集めるUAはこれらメタ情報をデータベースに登録するかもしれません。檢索結果のサマリーとして提示するかもしれません。情報の一部として記録するでせう。これらのmeta宣言はhead要素の中身において,出來るかぎり頭のはうに記述する必要があります。——を表してはなりません。4文書では,head要素の中身に必ず一つのtitle要素があらねばなりません。中身が何もない空のタイトルでもいけません。title要素の中身にはあらゆる文字(文字參照やアクセント附き文字など)を含めて構ひませんが,コメント宣言も含めて,ほかのマークアップが現れてはなりません。4文書において唯ひとつ省略することが許されない,最も重要な要素であると捉へてください。どんなに有益な本であつてもその存在に氣附いて貰へなければ意味がありません。これはウェブ上のリソースにおいても同樣なのです。(註:文書タイトルが不明である場合,UAは代りにURLを示したりしますが,それはエラー處理の結果に過ぎません。視覺系ブラウザなら當然タイトルバーに示されますし,音声ブラウザなら合成音聲により眞つ先に話されるでせう。文書の全體像を把握するのが困難な非視覺系メディアでは,タイトルは特に重要と言へます。他にも,ブックマーク登録時の初期名稱や,履歴情報として保持されたり,檢索結果の一覽にも用ゐられます。あなたの文書を何處かで紹介したいと考へる人もゐるでせう。その時にうまく紹介できないやうな役に立たないタイトルではいけません。言ひ換へれるならば,讀者がタイトルだけを見てアクセスすべきかどうか判斷できる材料になるやう,工夫すべきなのです。文書タイトルは必須——重要な事から簡潔に著者は短すぎず,長すぎず,文書の内容を收斂させた簡潔な文書タイトルを提供すべきです。4.01の概説』とするなど。title要素に記す内容の順序は,始めに「その文書自身の名前」を記して,次いで「屬するリソース群の名前」を連結するのが好ましいでせう。GUIや檢索結果のタイトル欄といふのはその面積が屡々制限されて,後ろのはうの内容は省かれて仕舞ふからです。肝腎な主題が見えなくては困ります。音聲ブラウザでは毎囘リソース群の名前から話し始められると煩しいので,これを避ける意圖もあるのです。【圖】タブ型ブラウザ——タブの幅は制限される事が多く,タイトルの後方は省かれてしまふ:フレームセット文書に據つて,あるいは行内フレーム(iframe要素)に據つて,結び附けられた各文書にも,適切な文書タイトルが必要です。Agentおよびユーザは,フレームとしてではなく,各文書に直接アクセスするかもしれません。各文書が獨立したひとつのリソースとしても識別できるやうにすべきです。非視覺環境の讀者は各フレームの概觀をひと目では把握できないので,文書タイトルは肝要です。Agentのカンヴァスにレンダリングされる實際の本文内容を記述します。視覺系ブラウザでは,テキスト,畫像,色,圖などの視覺的な整形構造が現れるカンヴァスを持ち,一般にはそのカンヴァスを表示域(viewport)に出力するでせう。Agentでは,一次元の時間の流れに伴つて(合成音聲で)話される,音聲空間としてのカンヴァスを持つと考へられます。body要素のぢかには,少くとも一つ以上のブロックレヴェル要素を含める必要があります。斷片的なインライン内容(文字データやインライン要素)をぢかに含めてはなりません。4ではマーク附けで明示せずともbody要素の範圍が明確なら,この要素の開始タグと終了タグは共に省略可能です。ソース文書内にbody要素の開始タグや終了タグが存在しなくとも,適合UAはその存在を推量して,文書ツリーを正しく組立てます。それはブロックレヴェル要素と呼ばれるbody要素のぢかに含まれうる骨骼を成すものと,その行内で斷片的に插入されるインライン要素です。ブロックレヴェル要素のはうがより大きな構造を成します。ブロックレヴェル要素とは,謂はば『ひと固まりの完結した思想』であり,大きな構造を成します。視覺系UAはこれらの前後で行を分斷し,表示域の幅に應じた矩形ブロックとしてレンダリングするでせう。この見た目は飽くまで表現現象であり,本質ではありません。一方のインライン要素とは,謂はば『行内での斷片的な意圖』であり,小さな構造を成します。これらは常にブロックレヴェル要素の行内に分散して插入されます。テキスト内容が單一行で收り切らないなら,複數の行を跨いで分割してレンダリングされます。ブロックレヴェル要素型を擧げるとh1〜h6(見出し),p(パラグラフ),ul,ol,dl(リスト),blockquote(ブロックレヴェルの引用),address(問ひ合せ),pre(整形濟みテキスト),div(グループ化)などがあります。インライン要素型にはem,dfn,a,imgなどがあります。到逹するやうに階層構造を成すものです。文書の概觀を作り上げてゐます。據つて開始されるべきです。4の見出し構造では,h1〜h6要素に據つてそのセクションの開始を示すだけで,そのセクション自體の範圍を明示する仕組が無いことに注意してください。これはHTMLといふ言語が,なるべく複雜な階層構造を避けるやう,誰にでも簡單にマーク附けできるやう,設計されてゐるためです。Web研究室h1〜h6要素の中身には,そのセクションの話題をインライン内容(文字データやインライン要素)で簡潔に示します。文書の見出しは,文書の構造から見て最上位のh1要素から始り,h2要素,h3要素,h4要素......といふ順に最低位のh6要素まで,セクションの階層に應じてマーク附けします。見出しの數字は,見出しの階層レヴェルであつて,文字の大きさではありません。見出しレヴェルを飛ばすのは惡しき習慣です——たとへばh2要素からh4要素へ,といふ具合に。4では文法違反ではありません(より嚴格なISO-HTMLではエラーです)が,論理的に不自然ですし,見出しレヴェルを頼りにするユーザを混亂させます。一つのHTML文書は一つの完結したリソースであるべきで,文書の見出しはh1要素から始めるべきです(大きな話題を一つの文書で扱ひ,文書を分割しない)。h1要素にはリソース群の名稱ではなく,その文書自身の要約を記述すべきです(ブログや掲示板などは例外)。文書本文の末尾にフッタのセクションを設けるなら,そこにもフッタの開始となる見出し要素が必要です。ないと構造上,そのフッタは直前の見出しセクションの内部に收容されてしまひます。視覺系ブラウザは慣例として,より上位の見出しを大きく,より低位の見出しを小さくレンダリングします。左右されて,不適切に濫用してはなりません。見出しの外觀は,著者スタイルシートの指定に據つて,どのやうにでも變更できます。見出しの拾ひ讀み/編輯ユーザは見出しを利用して,文書を拾ひ讀みするかもしれません。自動生成して,目的の位置にすばやく移動できるかもしれません。キー操作などで前後の見出し位置へすばやく移動できるかもしれません。このやうな機能は,文書を限られた狹い表示範圍でしか見れない,もしくは全く見れない人々にとつて特に有益です——たとへば合成音聲による讀み上げ,弱視もしくは畫面から遠いための擴大表示,狹い畫面解像度での利用者,視野狹窄の障礙を持つ人など。見出し要素は,ユーザだけでなく著者に役立たせることも可能です。テキストエディタに依つては,見出し要素を自動收集して,その編輯行に移動できるメニューを用意するかもしれません。文書内もしくは目次文書で用ゐるための目次リストのマークアップを自動生成する機能が提供されるかもしれません。著者自身がマクロに據り,このやうな見出しを役立たせる機能を獨自に實裝することも可能です。以下に,見出し要素を活用してゐるソフトウェアまたは擴張機能をいくつか紹介します:iCab(Mac用)コンテキストメニューから「ページの概観」として,見出しを階層的にリストアップしてくれる。OperaS/Wキーによつて,現在の表示範圍で最も近い前後の見出し位置に移動できる。ホームページ・リーダー(音聲ブラウザ)「見出し読みモード」によつて,文書内の見出し要素だけを順番に讀んで行くことができる。このとき,見出しレヴェルも合せて讀み上げられるので,文書の階層も把握可能になつてゐる。Firefox(拙作)......Bookmarkletで見出し一覽。コンテキストメニュー拡張(piro氏作)......iCabとOperaの機能を再現できる。べんりセット(ありみか氏作)......「見出し一覧」の機能が含まれる。WinIEIEコンテキストメニューセット(さつぱり氏作)......「見出しツリー」の機能が含まれる。べんりセット(ありみか氏作)......「見出し一覧シート」の機能が含まれる。秀丸エディタ見出しツリー生成マクロ(piro氏作)......目次リストを生成してクリップボードに格納できる。見出し位置へ移動するマクロ(拙作)......見出し要素の編輯行に移動できる(その畫像)。ez-HTMLスペシャルサイドバーの「アウトライン解析」によつて,見出し一覽/移動ができる。likeな高度なテキストエディタです。treeviewライブラリで,見出しアウトラインを表示できます(その畫像)。li要素やdt要素も階層に插入されます。見出しセクションの上/下を入替へたりも出來ます。address要素address要素は,文書全體,または文書内の主要部分に對して,問ひ合せ情報(著者名・メールアドレスなど)を提供する際に用ゐられます。一般慣習では,文書本文の冒頭か末尾にフッタのセクションを設けて,その範圍の中で利用されます。出現囘數は制限されないので,その他のセクションで用ゐても構ひません。簡単なHTMLの説明address要素の中身には,文字データに加へてインライン要素を含められますが,ブロックレヴェル要素は一切含められません。したがつて,何らかの意圖でテキストを複數行に分けて記述したい場合には,br要素を用ゐて強制的に行區切りを生じさせる事になります。情報を明確に記して置くべきです。ひハイパーリンクの繋がりで一つのサイトに見えてゐても,各文書はひとつのURIが與へられた獨立したリソースである事に變りありません。ひと綴りの書物では奧附の一頁に記して置けば濟みますが,ウェブ文書では銘々が完結した單一のリソースとして見做されので,各文書ごとに著作情報が必要なのです。著作情報をaddress要素として示すかどうかは意見が分かれるやうで,address要素を懷疑的に捉へる人々もゐます。彼らは,著者情報は文書の本文として示せずとも,ヘッダ情報としてmeta要素やlink要素で示すことで充分に役割を果たす,と云ふのです。[CS]この屬性は要素に名前をわりあてます。何かしらの固有性をもつ單一の要素について,一意識別子をわりあてるために用ゐられます。値はa〜zA〜Zで始まり,任意のa〜zA〜Z,0〜9,ハイフン(-),アンダースコア(_),コロン(:),ピリオド(.)。[CS]この屬性はある要素に單一のクラス名をわりあてるか,空白類の區切りで複數のクラス名を設定します。これは複数の要素をまとめる分類として,同じクラス名の集合を文書内で何囘でも與へる事ができます。10646)に含まれる任意の文字列。(補足:[CS]——大文字と小文字を區別することを意味する。大文字と小文字が異るだけのid屬性の名前は,一意性に缺けるので,同一文書中で同時に出現してはならない。いふid屬性の名前なら,この兩者は同一文書中で同時に出現できない。)HTMLにおいてid屬性は次のやうな役割を果たします:スタイルシート規則でスタイルの對象先を決定するためのセレクタ。文書内のある特定個所へリンクする爲に用ゐられる終點アンカー。スクリプトにおいて要素を一意に取得して,處理するための手段。HTML文書を別フォーマットに變換するなど。HTMLにおいてclass屬性は次のやうな役割を果たします:要素集合に對して分類的にスタイル情報をわりあてるためのセレクタ。スクリプトを用ゐて,要素の表現方法を動的に切替へるための手段。メタデータとして收集して,情報を提示するなど。これらの屬性は,要素を識別するための手段として樣々に利用され得ます。著者は自身によつて,あるいはユーザによつて,それぞれの識別子がどのやうに利用されうるのか,考慮する必要があります。あとで變更せずに濟むやうな普遍的な名前を檢討すべきです。見た目に依存しない名前idおよびclass屬性には,視覺的なスタイルに關聯した名前を附けるべきではありません。色,テキスト效果,フォント,餘白,枠,配置,寸法に關聯するもの等です。このやうな名前を用ゐてしまふとウェブデザインが恣意的になり,保守性を落とします。著者のスタイル構想が變化してしまふと,必然的にマーク附けが破綻してしまふからです。スタイルの再設計に據つて,文書の再構築を強ひられるのです。名前附けは,視覺的な發想によるものではなく,その要素が持つべき本質的な事柄をあらはす名稱を用ゐるべきです。abstract,article,sectionなどの語を用ゐてゐれば,後でスタイルシートを再設計する際にも,文書のマーク附けを變更せずに濟みます。或る文書に對應するスタイルシートは,一對一に限られず,一對多であつても良い點に,注目すべきです。4仕樣で定められてゐる優先・代替スタイルシートの仕組を用ゐると,選擇可能な多種類のスタイルシートをユーザに提供できます。單一の要素を『固有の存在』として識別します。文書内で要素を一囘だけ識別すれば良いから,といふ理由だけでid屬性を指定すべきではありません。ないのか,よく檢討すべきです。その要素が固有の存在であり,何かの分類にも屬するなら,id屬性とclass屬性を併用しても構ひません。著者は,分類であるclass屬性の役割と混同して,id屬性の名前を文書内で何度も重複させてはなりません。Agentは複數ある同じアンカー名から一體どれを選べば好いといふのでせうか。Agentはこのやうなエラー状態を何かしらの方法で囘避すると考へられますが,著者とユーザの雙方は,特定のエラー復元に依存してはなりません。div要素とspan要素これらは,前述のidまたはclass屬性と併用して,文書に構造を附加するメカニズム一般として提供されます。それぞれインラインであるか(span),ブロックレヴェルであるか(div)は定められますが,そのほかのレンダリング效果は現れません。それゆゑに著者は,これらの要素に對してスタイルシートやlang屬性などを指定して,文書を自身の要求や趣向に應じさせられます。divやspanばかりに依存してはなりません。Agentが理解可能であるやうに設計すべきものです。スタイルシートの下地として,HTML文書が存在してゐるのではありません。これらの要素は,謂はば『匿名の要素』であり,いかなる意味論を持ちません。これらにclassやidを割り當てたしても,それに據つて意味が生じる訣ではありません。idまたはclass屬性の名前に意味があるとしても,その意味を直接的に理解できるのは人間のみです。div要素のぢかはブロックレヴェル要素だけで構成されるべきです。div要素のぢかに斷片的な情報である筈のインライン内容を存在させるのは,好ましくありません。して意圖する,div要素(もしくはその他のブロックレヴェル要素)のセクションを補足するために,しばしば利用されます。ある例としては,body要素のぢかに現れる大きな骨骼構造を意圖して,ヘッダ部(header),ナヴィゲーション部(navigation),主内容(main),フッタ部(footer)などのやうなグループを構築する,といふ設計方法がしばしば見られます。參考文獻を提示するリストは一つの文書内で頻繁に用ゐられるかもしれません。そのやうな機能ブロックは名前を附けて,分類として纏めておくと便利でせう。意味や構造をあらはすブロックレヴェル要素型を用ゐずに,div要素ばかりに依存してはいけません。HTMLで豫め用意されてゐる要素型——見出し(h1〜h6),パラグラフ(p),箇條書き(ul,ol),定義リスト(dl),引用ブロック(blockquote)など——を最大限に活用すべきです。Agentの對象メディアに合致した方法で適切に表現されます。改定:2007年02月15。