Translation of: What Does It All Mean? - Dive Into HTML5
この章ではまったく何も間違っていないHTMLのページを改善します。その一部は短くなるでしょうし、一部は長くなるでしょう。そして、その全てがもっと意味のあるものに(セマンティックに)なるでしょう。素晴らしいですよね?
題材となるページはここにあります。Learn it. Live it. Love it. 新しいタブでそのページを開き、「ページのソースを表示」するまでこのページに戻ってきてはいけません。
❧
まずは先頭から:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
これは「doctype」と呼ばれるものです。doctypeには長い歴史 ― 黒魔術的な ― があります。Mac版Internet Explorerでは、Microsoftの開発者自身が驚愕するほどの問題を発見したこともあります。来るべき新しいバージョンのブラウザーではWeb標準のサポートは改善され、古いウェブページは正しく表示されないでしょう。または正しく表示されている(仕様に従って)のにも拘らず、多くの人々がきちんと表示されていないと思うでしょう。ウェブページはNetscape 4やInternet Explorer 4といったシェアの優勢なブラウザーの癖に合わせて作成されていました。IE5/Macは非常に先進的なものでしたが、ウェブページをめちゃくちゃにしました。
Microsoftは奇抜な解決方法に辿り着きました。IE5/Macで通常HTMLソースの最初の行(<html>
要素より前)にある「doctype」を探すようにしたのです。古いウェブページ(古いブラウザの癖に依存した)は大抵の場合doctypeがありません。IE5/Macはそういったウェブページは古いブラウザと同じように表示し、新しいWeb標準を有効にしたい場合は正しいdoctypeを<html>
要素より前に置けば良いようにしました。
このアイディアはあっという間に広まり、全てのメジャーなブラウザーが「互換モード」と「標準モード」の二つのモードを持つようになりました。もちろんすぐに手に負えない状況に陥ることになりました。Mozillaはバージョン1.1をリリースしようとした時、「標準モード」で表示されているにも拘らず特定の癖に依存しているウェブページがいくつもあることを発見しました。Mozillaはレンダリング・エンジンを修正してその癖を修正しましたが、その結果一気に多くのウェブページがめちゃくちゃに表示されるようになりました。そのため ― でっちあげではないですよ ― なんと「ほぼ標準モード」なるものが作られてしまいました。
Activating Browser Modes with Doctypeで、Henri Sivonenはそれぞれのモードの違いを以下のようにまとめています:
- 互換モード
- 互換モードでは、1990年代終わりに流行った手法に基づいて作成されたウェブページをめちゃくちゃにしないためにWeb標準を無視します。
- 標準モード
- 標準モードでは、ブラウザはなるべく既に仕様に従った形で実装されている振る舞いに基づいて文書を表示しようとします。HTML5ではこのモードを「非互換モード」と呼んでいます。
- ほぼ標準モード
- FirefoxやSafari、Chrome、Opera(7.5以降)、IE8は「ほぼ標準モード」を持っており、表のセルの横方向のサイズをCSS2の仕様を無視して決定します。HTML5ではこのモードを「限定的互換モード」と呼んでいます。
(僕はとても簡潔に引用しているので、ちゃんとHenri Sivonenの記事の残りの全てを読むべきです。例えばIE5/MacではWeb標準としてサポートされていないいくつかの古いdoctypeがサポートされています。互換性のリストが増えるに従って「互換モード」として扱われるdoctypeは増えていきました。最後に僕が確認した時は、5つのdoctypeが「ほぼ標準モード」になり、73のdoctypeが「互換モード」になりました。しかし、それでもいくつか見逃しているでしょうし、Internet Explorer 8が4つ ― 4つですよ! ― の表示モードを切り替えられるといううんこみたいな機能については言及するつもりはありません。死ねば良いのに。燃えて死ね。)
さて何の話をしていたのでしょうか。そうです、doctypeですね:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
これは多くの現行ブラウザで「標準モード」で解釈される15のdoctypeの内の一つです。特に何も間違いはありません。もしこれを使いたいというのならそのまま使っても構いません。より短く簡潔で多くの現行ブラウザで「標準モード」になるHTML5のdoctypeに変更することもできます。
HTML5のdoctypeはこうです:
<!DOCTYPE html>
これだけです。たった15文字です。簡単なので、空で覚えてタイプできるでしょう。
❧
HTMLページは入れ子になった要素の塊です。その全体的な構造は木に似ています。いくつかの要素は「兄弟」であり、それは同じ幹から二本の枝が生えているようなものです。いくつかの要素は他の要素の「子」であり、それは大きな枝から小さな枝が生えているようなものです(別の言い方をするなら他の要素を含む要素その直下の要素に対する「親」で、その孫要素に対する「祖先」です)。子要素を持たない要素は「葉」ノードと呼ばれます。最も最上位の要素、つまりすべての要素の祖先に当たる要素はルート要素と呼ばれます。HTMLページではルート要素は常に<html>
です。
この例ではルート要素は以下のようになっています:
<html xmlns="http://www.w3.org/1999/xhtml"
lang="en"
xml:lang="en">
特にこのマークアップに間違いはありません。繰り返しになりますが、もしこれを使いたいというのならそのまま使っても構いません。これは妥当なHTML5です。しかし、HTML5では必須ではない部分がいくつかあり、それらを削除することで数バイト節約できます。
まずxmlns
属性について考えましょう。これはXHTML 1.0の名残りで、このページに含まれる要素はXHTML名前空間(http://www.w3.org/1999/xhtml
)に属するものであるということを教えてくれます。しかしHTML5の要素は常にこの名前空間に属するので、明示的に宣言する必要はもうありません。HTML5ページはこの属性があろうとなかろうと全てのブラウザで同じように解釈されるでしょう。
xmlns
属性を削除するとルート要素はこうなります:
<html lang="en" xml:lang="en">
HTMLページの言語を定義するlang
とxml:lang
という二つの属性がまだあります(en
は「英語」を意味します。英語ではない場合は自分の言語コードを探してみましょう)。なぜ同じことを二つの属性で表現するのでしょうか? これもXHTMLの名残りです。HTML5ではlang
だけが意味を持ちます。xml:lang
をそのままにしておいても構いませんが、必ずlang
属性と同じ値にしなければなりません。
To ease migration to and from XHTML, authors may specify an attribute in no namespace with no prefix and with the literal localname "xml:lang" on HTML elements in HTML documents, but such attributes must only be specified if a
lang
attribute in no namespace is also specified, and both attributes must have the same value when compared in an ASCII case-insensitive manner. The attribute in no namespace with no prefix and with the literal localname "xml:lang" has no effect on language processing.
もう削除してもいいでしょうか? 大丈夫なら削除してしまいましょう! ルート要素はこうなります:
<html lang="en">
ルート要素については以上です。
❧
<head>
Element大抵の場合ルート要素の最初の子は<head>
要素です。<head>
要素にはそのページの本文ではなくメタデータ ― そのページに関する情報 ― が含まれます(本文は当たり前ですが<body>
要素に含まれます)。<head>
要素そのものは退屈なもので、HTML5になにか面白い効果を与えるものではありません。面白いのは<head>
要素の中です。では再び題材のページを見てみましょう:
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>My Weblog</title>
<link rel="stylesheet" type="text/css" href="style-original.css" />
<link rel="alternate" type="application/atom+xml"
title="My Weblog feed"
href="/feed/" />
<link rel="search" type="application/opensearchdescription+xml"
title="My Weblog search"
href="opensearch.xml" />
<link rel="shortcut icon" href="/favicon.ico" />
</head>
まずは<meta>
要素からですね。
❧
「文章」について考える時、「コンピューターの画面に表示される文字や絵」についても考える必要があります。しかしながら、コンピューターは文字や絵を直接扱ってくれるわけではなく、ビットやバイトという単位で扱います。コンピューターの画面で見る文章は全てそれぞれの文字エンコーディングに従ったものです。数多くの文字エンコーディングが存在し、ロシア語や中国語や英語それぞれに最適化されたもであったり、複数の言語を扱うことができたりもします。簡単に言うと、文字エンコーディングはメモリやディスクに保存されたデータとコンピューターの画面での表示をマッピングするものです。
実際にはもっと複雑です。同じ文字が複数のエンコーディングにあり、それぞれが違うバイトの組み合わせでメモリやディスクに保存したりもします。文字エンコーディングを復号化の鍵のようなものだと考えても良いでしょう。誰かがテキストとして一連のバイトの組み合わせをおくってきた場合、文字として画面に表示(または印刷したりなど)する場合にはそれがどの文字エンコーディングなのか知る必要があります。
ではブラウザーはサーバーから送られてくる一連のバイトからどうやって文字エンコーディングを決定しているのでしょうか? 良い質問ですね! もしHTTPというものを知っているなら、以下のようなヘッダを見たことがあるでしょう:
Content-Type: text/html; charset="utf-8"
簡潔に言うと、これはウェブサーバーはHTML文書を送っていることと、その文書の文字エンコーディングがUTF-8
であることを教えてくれています。残念なことに偉大なるごった煮のWWWでは、限られた作成者しかHTTPサーバーを設定することができません。例えばBlogger: それぞれのコンテンツは個人が提供していますが、サーバーはGoogleによって運営されています。そのためHTML 4はHTML文書そのもので文字エンコーディングを指定することができるようになっています。以下のような文を見たことがありませんか? :
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
簡潔に言うと、これはウェブ制作者がHTML文書を文字エンコーディングとしてUTF-8
を使って作成したということを教えてくれます。
以上の二つのテクニックはHTML5でもそのまま機能します。HTTPヘッダーがもっとも強力な手段で、<meta>
タグがあってもそれを上書きすることができます。しかしみんながHTTPヘッダーを設定できるわけではないので、<meta>
タグも引き続き機能するようになっています。それどころかHTML5ではもっと簡潔に記述できるようになっています。ではどうなっているのでしょうか:
<meta charset="utf-8" />
全てのブラウザーできちんと作用します。この省略した記法はどこからきたのでしょうか?僕が見つけた中では以下のメーリングリストへの投稿が最もうまく解説していると思います:
The rationale for the
<meta charset="">
attribute combination is that UAs already implement it, because people tend to leave things unquoted, like:
<META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=ISO-8859-1>
もしブラウザーがちゃんとこの省略した記法を扱えるかということを信じることができないなら、<meta charset>
のテストがあるのでそれを参照してみてください。
質問: 変わった文字を使うつもりはないんですが、それでも文字エンコーディングを指定したほうが良いのでしょうか?
答え: 指定してください! 全てのHTMLページで文字エンコーディングを指定するべきです。エンコーディングを指定しない場合、セキュリティ的な問題を抱えることになるかもしれません。
かいつまんで言えば、文字エンコーディグは複雑で、教養のある人々が使う多くのお粗末なソフトウェアではコピーアンドペーストで普通に扱えるほど簡単になっていません。全てのHTML文書で必ず文字エンコーディングを指定するべきで、そうしないと良くないことが起こります。HTTPのContent-Type
ヘッダーでも良いですが、<meta http-equiv>
かもっと短い<meta charset>
での宣言を書いて欲しいです。きっとインターネットも喜びます。
❧
通常のリンク(<a href>
)は単純に他のページを参照します。<link rel>
はなぜ他のページを参照しているのかを説明するものです。これらは「僕はこのページを参照します。なぜなら…」という文章を完成させます:
などなど。HTML5ではリンクの関係性を二つに分けています:
Two categories of links can be created using the link element. Links to external resources are links to resources that are to be used to augment the current document, and hyperlink links are links to other documents. ...
The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type.
題材として取り上げた例では、最初の(rel="stylesheet"
)だけが外部のリソースへのリンクです。残りの全ては他の文書へのハイパーリンクになっています。これらのリンクは辿っても辿らなくても構わないですし、このページを閲覧するために参照する必要があるわけでもありません。
多くの場合リンクの関係性はウェブページの<head>
の中で<link>
要素の一部として出現します。いくつかのリンクの関係性は<a>
要素でも使えますが、あまり知られていません。HTML5では<area>
要素でも使うことができるようになりましたが、更に知られていないでしょう(HTML 4ではrel
属性を<area>
要素で使うことはできません)。完全なリンクの関係性の表を見て、どのような値をrel
として指定できるかチェックしてみましょう。
質問: 自分で勝手にリンクの関係性を作ってもいいのでしょうか?
答え: そうすると無限に新しいリンクの関係性が作られ続けることになるでしょう。色々な人がうんこのようなものを作るのをやめさせるために、WHATWGでは提案されたrel
の値を管理しており、どうやって承認されていくかを説明しています。
それでは題材のページの最初のリンクの関係性を見てみましょう:
<link rel="stylesheet" href="style-original.css" type="text/css" />
これは最もよく使われるリンクの関係性でしょう(文字通りに)。<link rel="stylesheet">
はCSSルールが書かれた外部ファイルを指し示します。type
属性を削除することだけがHTML5でできる最適化です。スタイルシートの言語としてウェブ上ではCSSしかないので、type
属性のデフォルトの値になっています。全てのブラウザーで同じように作用するでしょう(もし新しいスタイルシートの言語がいつか作られたとしてもtype
属性を追加すれば良いだけです)。
<link rel="stylesheet" href="style-original.css" />
続けて題材のページを見てみましょう:
<link rel="alternate"
type="application/atom+xml"
title="My Weblog feed"
href="/feed/" />
このリンクの関係性もよく知られています。<link rel="alternate">
をtype
属性でRSSやAtomのメディア・タイプと組み合わせると「feed autodiscovery」という仕組みが有効になります。これにより、フィード・リーダー(例えばGoogle Readerのような)が最新の記事が載っているフィードを自動的に見つけることができるようになります。多くのブラウザはURLの横に特別なアイコンを表示してくれたりもします。rel="stylesheet"
と違い、type
属性はとても重要です。削除しないようにしましょう!
rel="alternate"
というリンクの関係性は実に様々な使い方をされます。HTML 4においてすらそうです。HTML5では、その定義を既存のウェブ上のコンテンツをより正確に表現できるように詳細に書きなおし、はっきりとさせました。上記のように、rel="alternate"
をtype=application/atom+xml
と共に使用した場合、そのページのAtomフィードを指し示すことになります。しかし、rel="alternate"
を別のtype
属性と共に使用することによって、例えばPDFのような同じ内容の別のフォーマットを指し示すこともできます。
HTML5では文書の翻訳に対してどうリンクを張れば良いのかという長らく混乱していた状況についても解決しました。HTML 4ではlang
属性をrel="alternate"
と共に使用してリンク先の文書の言語を宣言していましたが、これは間違いでした。HTML 4 ErrataではHTML 4仕様の4つの完全な間違いをリストアップしています。それら完全な間違いのうちの一つがrel="alternate"
でリンクが張られた文書の言語を宣言する方法です。HTML 4 ErrataやHTML5で定められている正しい方法では、hreflang
属性を使います。残念ながらこれらの正誤表はもうHTML 4仕様に反映されることはありません。W3C HTML Working Groupの誰もHTMLの策定に従事していないからです
rel="archives" ― 記録や文書など過去の記録の一覧を参照する文書を指し示します。ブログのインデックス・ページからrel="archives"を使用して過去ログのインデックス・ページへのリンクを張ることができるでしょう。
rel="author"
はそのページの制作者へのリンクに使用します。mailto:
アドレスでもそうでなくても構いません。連絡フォームへのリンクでも「制作者について」のページへのリンクでも良いでしょう。
rel="external" ― その文書が含まれるサイトの一部ではない文書を指し示します。僕の記憶ではWordPressがコメントの投稿者が残したリンクに使ったところから広まったと思います。
HTML 4ではrel="start"
やrel="prev"
、rel="next"
を一連の文書(書籍の章立てやブログへの投稿など)の関係性を示すために規定しています。きちんと使われているのはrel="next"
だけです。多くの人々はrel="previous"
をrel="prev"
の代わりに使用したり、rel="begin"
とrel="first"
をrel="start"
のかわりに使用したり、rel="end"
をrel="last"
の代わりに使用したりしています。加えることに、rel="up"
で「親」ページを指し示したりもしています。
HTML5では「一連の中で最初のページ」を表現するために使われていた様々のものの中から最も一般的だったrel="first"
を含めることにしました(rel="start"
は後方互換性のために提供される同じ意味を持つものです)。他にHTML 4と同じくrel="prev"
やrel="next"
、後方互換性のためにrel="previous"
やrel="last"
(一連の中で最後のページ、つまりrel="first"
の反対)、rel="up"
も含まれます。
rel="up"
についてはパンくず・ナビゲーションを思い起こしてみると良いでしょう。ホーム・ページがパンくず・ナビゲーションの最初のページで、現在のページは最後になっているでしょう?rel="up"
はパンくず・ナビゲーションの最後のページのすぐ隣りを指し示すことになるでしょう。
rel="icon"はrel="stylesheet"
に続いて二番目に有名なリンクの関係性です。通常はshortcut
と共に以下のように使用されます:
<link rel="shortcut icon" href="/favicon.ico">
全てのメジャーなブラウザは小さなアイコンをそのページを関連付けてくれます。ロケーション・バーのURLのすぐ隣や、ブラウザのタブ、もしくはその両方に使われることが多いです。
HTML5の新機能: icon
と共にsizes
属性を使用することによって参照されるアイコンのサイズを示すことができます。
rel="license"はmicroformatsで考案されました。現在の文書がどのようなライセンス形態で提供されているのか説明している文書を指し示します。
rel="nofollow"はリンク先がそのページの製作者や発行者が承認していない、または参照される文書が主に商業的な意図を持っていることを指し示します。これはGoogleが考案したもので、microformatsにより標準化されました。WordPressはrel="nofollow"
をコメントに含まれるリンクに追加しています。「nofollow」なリンクがPageRankに影響を与えないのなら、スパム業者がスパムコメントをブログに投稿するのを諦めるのではないかという考えによるものでした。そうはなりませんでしたが、依然としてrel="nofollow"
は使われています。
rel="noreferrer"はリンク先にリファラーを送信しないように指示します。現行のブラウザはサポートしていませんが、WebKit nightlyでサポートされたので、近いうちにSafariやGoogle Chrome、他のWebKitベースのブラウザーでサポートされるようになるでしょう。[rel="noreferrer" test case]
rel="pingback"は「pingback」サーバーのアドレスを指し示します。Pingbackの仕様によると、「pingbackシステムは他のウェブサイトからリンクを張られたことを通知するものです。…このようにしてリンクのチェーンを逆に辿ることが可能になります」と説明されています。ブログ・システム、特にWordPressではpingbackが実装されており、新しい投稿でリンクを張ったページの製作者に通知されるようになっています。
rel="prefetch"はユーザーがまず間違い無く参照するであろうことから、先読みしてキャッシュするために参照すべきリソースを指し示します。検索エンジンは検索結果で一位のページが他の結果よりも圧倒的にポピュラーな場合、しばしば<link rel="prefetch" href="URL of top search result">
を検索結果のページに追加しています。例えばFirefoxを使ってCNNをGoogleで検索し, ソースを開き、prefetch
というキーワードを検索してみてください。Mozilla Firefoxだけがrel="prefetch"
をサポートしています。
rel="search"はその文書とそれに関連したリソースを検索するためのインターフェイスが含まれた文書を参照していることを示します。特にrel="search"
を有益なものにしたいなら、ブラウザーがどうやって与えられたキーワードで現在のサイトを検索するURLを構築すれば良いかを定義したOpenSearchに従った文書を指し示すようにするべきでしょう。OpenSearch (とOpenSearch定義文書を指し示すrel="search"
)はMicrosoft Internet Explorer 7以降とMozilla Firefox 2以降でサポートされています。
rel="sidebar"は参照先の文書が現在参照中のコンテキストに対して副次的なコンテキストに読み込まれるべき文書であることを指し示します。どういう意味かというと、OperaとMozilla Firefoxでは「そのリンクをクリックした場合、ブックマークするかどうか尋ねられ、ブックマークから選択された場合にはそのリンク先のドキュメントをブラウザのサイドバーで開く」という意味合いになっています(Operaでは「sidebar」ではなく「panel」と呼ばれています)。Internet ExplorerやSafari、Chromeはrel="sidebar"
は無視され、普通のリンクと同様に扱われます。[rel="sidebar" test case]
rel="tag"は現在の文書に付けられたタグを代表する文書を指し示します。rel
属性を使用した「タグ」(カテゴリのキーワード)付けは、ブログへの投稿のカテゴリ分けを容易にするためにTechnoratiによって考案されました。初期のブログやチュートリアル・サイトはそうやってタグを「Technoratiタグ」と関連付けていました(You read that right: 営利企業がありとあらゆるものにメタデータを付ければもっと仕事がやりやすくなるだろうと説得したのです。Nice work if you can get it!)。後にmicroformatsで標準化され、rel="tag"
などと呼ばれるようになりました。多くのブログ・システムはrel="tag"
によってカテゴリやキーワードまたはタグに個々の投稿を関連付けることができるようになっています。ブラウザーはこれらを利用して何か特別なことを行ったりはしません。主に検索エンジンがそのページがどうのような事柄について書かれているのかの目安として利用することが念頭に置かれています。
❧
HTML5は単に既存のマークアップを短くするというだけものではありません(大体において適当な長さに短くしてくれもするでしょうが)。新たにセマンティックな要素を定義してもいます。
<section>
section
要素はドキュメントやアプリケーションの一般的なセクションを表現します。ここで言うところのセクションとはあるテーマに即したコンテンツの集合のことで、往々にして見出しが付いています。セクションの例としては書籍の章やタブ付きダイアログのそれぞれのタブページ、論文の番号が割り振られた節などが挙げられるでしょう。ウェブサイトのホームページでは前置きや新着記事、連絡先情報などをそれぞれセクションとして区切ることができるはずです。<nav>
nav
要素は他のページへのリンクやそのページ内でのリンクを含むセクションを表現します。つまりナビゲーションリンクを含むセクションです。全てのリンクの集合がnav
要素以下になければならないかというとそういうわけではありません ― メジャーなナビゲーション・ブロックからなるセクションのみがnav
要素としてふさわしいです。フッターによくあるウェブサイトの主なページやサービス利用規約、ホームページ、著作権情報へのリンクで使われることが多いです。footer
要素はそれだけでそういったケースに十分対応することはできるので、必ずしもnav
要素を使う必要はありません。<article>
article
要素は、例えばそれだけでフィード等で配信可能であったり再利用できたりするそれ自身で完結している文書、ページ、アプリケーション、ウェブサイトを表現するものです。フォーラムへの投稿や雑誌や新聞の記事、ブログのエントリ、ユーザーの投稿したコメント、対話式のウィジェットやガジェット、その他独立したコンテンツ部分などに使うことができます。<aside>
aside
要素はaside
要素でくくられた部分が本文からは少し脱線していて、本文とは別個のものとして捉えて欲しいセクションを表現します。新聞や雑誌などの印刷媒体で言うところのサイドバーのようなセクションを表現することもあります。具体的には引用やサイドバー、広告、nav
要素の集合の他、ウェブページのメインとなるコンテンツから分離させたいようなものに使うことができます。<hgroup>
hgroup
はセクションの見出しを表現します。この要素は小見出しがあったり、別の表現をされた見出しがあったり、キャッチフレーズがあったりすることで複数のh1
~h6
要素が出現する場合にそれらをまとめるために使われます。<header>
header
要素は前置きやナビゲーションの助けになるもののまとめを表現します。header
要素は主にセクションの見出し(h1
~h6
要素またはhgroup
要素)をくくるために使われることが多いが、必須というわけではありません。またheader
要素にはセクションの目次や検索フォーム、適切なロゴなどを含めることができます。<footer>
footer
要素は直近の祖先またはルート要素に当たるセクションのフッターを表現します。多くの場合フッターには誰が書いたのかとか関連した文書へのリンク、著作権情報などそのセクションに関する情報が含まれます。フッターはセクションの最後に置かなければならないというわけではなく、単に多くの場合そうなっているというだけです。footer
要素でセクション全てをくくってやれば、それらで付録や目次、長い奥付け、冗長なライセンス許諾条件などを表現することができます。<time>
time
要素は24時間表示での時刻や予測的グレゴリオ暦に基づいた正確な日付、その場合にはオプションとして時刻や時差なども含めたもの、を表現します。<mark>
mark
要素は参照されることを考慮してマークされたりハイライトされた文書内の一連の文字列を表現します。もしこの章をまだ読み終えてないのなら、これらの新しい要素を使用することに不安を覚えていることでしょう。しかし、少しだけ遠回りする必要があります。
❧
どのブラウザーにも既にサポートしているHTML要素についての習得済みリストがあります。例えばMozilla FirefoxのリストはnsElementTable.cppに格納されており、このリストにない要素は“不明な要素”として扱われます。不明な要素には二つの根本的な問題を抱えています:
<p>
は上下に空間をとり、<blockquote>
は左に余白を取ってインデントされ、<h1>
は大きなフォントで表示されます。ですが不明な要素の場合はどのようなスタイルを適用すれば良いのでしょうか?nsElementTable.cpp
にはそれぞれの要素がどのような要素を内包できるかという情報が含まれています。もしマークアップに<p><p>
というようなコードを含めたら、二つ目の段落要素は一つ目のを自動的に閉じるので、この二つの要素は親子関係ではなく兄弟関係になります。しかし、<p><span>
というようなコードを書いた場合は、Firefoxは<p>
がブロックレベル要素でインライン要素である<span>
を内包できることを知っているので、span
要素は段落を閉じません。つまり、DOMでは<span>
は<p>
の子ということになります。ブラウザーごとにこの問題について違う答えを持っています(僕はそれを知って衝撃を受けました)。最も有名なMicrosoft Internet Explorerによるこれらの問題について答えが最も多くの問題をはらんでいますが、どのブラウザーでも多少の手助けが必要になります。
最初の問題への答えはかなり簡単で、不明な要素に対して特に何もスタイリングしないことです。ページ内に現れる位置に従ってCSSプロパティを継承させ、ページ製作者にCSSで不明な要素をスタイリングできるようにすれば良いのです。これで大体はうまくいきますが、ひとつだけ気をつけるべきことがあります。
全てのブラウザーは未確認の要素をインライン要素として表示します。すなわちまるでdisplay:inline
というCSSルールを持っているかのように。
HTML5では新しい要素うちいくつかはブロック要素として定義されています。そのため、それらは他のブロックレベル要素を内包することができ、HTML5対応ブラウザーではデフォルトでdisplay:block
としてスタイリングします。もし古いブラウザでもこれらの要素を使いたい場合は、手動で表示スタイルを定義しないといけません:
article,aside,details,figcaption,figure,
footer,header,hgroup,menu,nav,section {
display:block;
}
(このコードはこの章内では触れないようなことについてもいろいろやってくれるRich ClarkのHTML5 Reset Stylesheetから取ってきたものです。)
あれ、これってダメじゃないですか! バージョン9より前のInternet Explorerでは不明な要素に対してまったくスタイリングすることができません。例えば以下のようなマークアップがあったとします:
<style type="text/css">
article { display: block; border: 1px solid red }
</style>
...
<article>
<h1>Welcome to Initech</h1>
<p>This is your <span>first day</span>.</p>
</article>
Internet Explorer (IE 8も含めて)では<article>
要素をブロックレベル要素として扱ってくれず、赤い枠線を記事の周りに引いてもくれません。全てのスタイル・ルールは単に無視されます。Internet Explorer 9はまだベータ版ですが、Microsoft はInternet Explorer 9ではこの問題は起こらないと発表しています(開発者も確認済みです)。
二つ目の問題は不明な要素を見つけた時にブラウザーがどういったDOMを構築するべきかというものです。またしてもInternet Explorerが最もやっかいです。IEは要素名が認識できない場合、その要素を子を持たない空ノードとしてDOMに追加してしまいます。そして不明な要素の子に当たるすべての要素はその兄弟として追加されます。
ASCIIアートを使ってその違いを図解してみましょう。以下はHTML5におけるDOMです:
article | +--h1 (child of article) | | | +--text node "Welcome to Initech" | +--p (child of article, sibling of h1) | +--text node "This is your " | +--span | | | +--text node "first day" | +--text node "."
対してInternet Explorerは以下のようなDOMを構築してしまいます:
article (no children) h1 (sibling of article) | +--text node "Welcome to Initech" p (sibling of h1) | +--text node "This is your " | +--span | | | +--text node "first day" | +--text node "."
この問題については不可思議な解決法があります。<article>
要素が出現するより前にJavaScriptでダミーとしてその要素を作成すると、不思議なことにInternet Explorerは<article>
要素を認識するようになり、CSSでスタイリングできるようになります。そのダミー要素はDOMに追加する必要はまったくありません。IEが認識できない要素をスタイリングできるように、単に一度だけ要素を作成(ページごとに)してやるだけです。
<html>
<head>
<style>
article { display: block; border: 1px solid red }
</style>
<script>document.createElement("article");</script>
</head>
<body>
<article>
<h1>Welcome to Initech</h1>
<p>This is your <span>first day</span>.</p>
</article>
</body>
</html>
このテクニックはIE 6を含めた全てのバージョンのInternet Explorerでうまく作用します。HTML5で新たに策定された要素全てに対して同じテクニックを流用する ― 繰り返しますがDOMには何も追加する必要はないので、ダミー要素を目にすることはないでしょう ― ことができるので、それらの新しい要素をHTML5非対応ブラウザでも特に意識せずに使えるようになります。
Remy SharpはこのテクニックをHTML5有効化スクリプトという実に適切な名前で公開してくれました。このスクリプトは既に14回も更新されていますが、基本的には以下のようなコードに基づいたものです:
<!--[if lt IE 9]>
<script>
var e = ("abbr,article,aside,audio,canvas,datalist,details," +
"figure,footer,header,hgroup,mark,menu,meter,nav,output," +
"progress,section,time,video").split(',');
for (var i = 0; i < e.length; i++) {
document.createElement(e[i]);
}
</script>
<![endif]-->
<!--[if lt IE 9]>
と<![endif]-->
は条件付きコメント(コンディショナル・コメント)というものです。Internet Explorerではこれらをif
式のように扱います: もし現在のブラウザーのバージョンがバージョン9より下なら、このブロックは実行されます。他のブラウザーは全てこのブロック全体をHTMLのコメントとして扱います。というわけでInternet Explorer (バージョン8までの)はこのスクリプトを実行し、他のブラウザはこのスクリプトを完全に無視することになります。こうすることでこのハックを必要としないブラウザではページの読み込みが速くなるでしょう。
このJavaScriptのコードは簡単明瞭なものです。eは"abbr"
や"article"
、"aside"
などといった文字列の配列で、その配列をループで回してdocument.createElement()
で要素を作成しています。そして返り値を無視することによって、DOMに要素が追加されないようにしています。これでInternet Explorerもこれらの新しい要素を、このページでも後ほど利用しますが、我々が望む程度には扱ってくれるようになります。
「ひとつだけ」重要なことがあります。このスクリプトはウェブページの最後ではなく先頭、できれば<head>
要素内、に書く必要があります。そうすることによってInternet Explorerはウェブページのタグや属性をパースするより前にこのスクリプトを実行してくれます。もしウェブページの最後に書いた場合、実行されるのが遅すぎるので、Internet Explorerはマークアップを間違って解釈した上、間違ったDOMを構築してしまいます。そういった間違いを修正することはこのスクリプトでは不可能だということも理由です。
Remy Sharpはこのスクリプトを「短縮させ」、Google Codeで公開しています(このスクリプトはオープンソースで、かつMITライセンスなのでどんなプロジェクトにも利用することができます)。望むのならGoogle Codeでホスティングされているコードを以下のようにして直接使うこともできます:
<head>
<meta charset="utf-8" />
<title>My Weblog</title>
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
これでようやくHTML5の新しいセマンティックな要素を利用することができるようになりました。
❧
それでは例としてあげたウェブページに戻りましょう。まずはヘッダーだけを見てください:
<div id="header">
<h1>My Weblog</h1>
<p class="tagline">A lot of effort went into making this effortless.</p>
</div>
…
<div class="entry">
<h2>Travel day</h2>
</div>
…
<div class="entry">
<h2>I'm going to Prague!</h2>
</div>
特にマークアップにおかしいところはありません。もしこれを使いたいというのならそのまま使っても構いません。HTML5として妥当なものです。しかしながらHTML5ではヘッダーやセクションに対していくつかのセマンティックな要素を提供しています。
まずは<div id="header">
を削除してみましょう。この部分はよく見かけるものですが、何か特別な意味のあるものではありません。div
要素は特別な意味を定義されていませんし、id
属性も同じように特別な意味を持ちません(ユーザーエージェントはid
属性の値が何らかの意味があるように扱ってはいけません)。この部分を<div id="shazbot">
と置き換えたとしても同じ意味合いすなわち何の意味も持ちません。
HTML5ではこのようなケースに使う要素として<header>
要素が定義されています。HTML5の仕様では<header>
要素の具体的な使用例についても触れられています。題材としたページではどうなるでしょうか:
<header>
<h1>My Weblog</h1>
<p class="tagline">A lot of effort went into making this effortless.</p>
…
</header>
これだけで良いのです。これだけでこれがヘッダーであることを誰でも知ることができます。しかしキャッチフレーズはどうしたらいいのでしょうか? この部分もまたWeb標準として今まで特に定義されていなかったのでよく見かけるものです。これをマークアップするのはなかなか難しいでしょう。キャッチフレーズは小見出しと似たものですが、大見出しに「くっついて」います。つまるところこれはセクションを伴わない小見出しということになります。
見出し要素である<h1>
や<h2>
はウェブページを構造化します。これらを同時に使うことによってウェブページを図解したり(辿ったり)するために使うことができるアウトラインを作成することができます。ウェブページ読み上げソフトウェアは文書のアウトラインを使って盲目のユーザーがウェブページ内の移動を行えるようにしています。文書のアウトラインを視覚化するためのオンラインツールやブラウザーの拡張もあります。
HTML 4では、<h1>
~<h6>
要素だけが文書のアウトラインを作成できました。例としてあげたページのアウトラインは以下のようなものになります:
My Weblog (h1) | +--Travel day (h2) | +--I'm going to Prague! (h2)
これはこれで問題ありませんが、「A lot of effort went into making this effortless」というキャッチフレーズをマークアップする手段がありません。もし<h2>
を使ってマークアップすると、文書のアウトラインに見せかけだけのノードが作られてしまいます:
My Weblog (h1) | +--A lot of effort went into making this effortless. (h2) | +--Travel day (h2) | +--I'm going to Prague! (h2)
これではこの文書の構造として適切ではありません。キャッチフレーズはセクションを作らない、単なる小見出しでしかないのです。
それではキャッチフレーズを<h2>
、そして各記事のタイトルを<h3>
にすれば良いのでしょうか? いいえ、そうしてしまうともっとおかしな事になります:
My Weblog (h1) | +--A lot of effort went into making this effortless. (h2) | +--Travel day (h3) | +--I'm going to Prague! (h3)
見せかけだけのノードが作れてしまう上、本来なら最上位のノードに属するはずの子を「奪いとって」しまいます。以上のことから、HTML 4では小見出しを文書のアウトラインに追加することなくマークアップする方法がないという問題を抱えていることが明らかになりました。この問題に対してどうあがいても「無駄な努力の積み重ね」という結果に終わります。というわけで<p class="tagline">
というようなセマンティクス的にまったく意味のないマークアップをするようになってしまったのです。
HTML5では<hgroup>
要素によってこの問題を解決できます。<hgroup>
要素は二つ以上の関連する見出し要素をまとめてくれます。「関連する」とはどういう意味でしょうか? それら見出し要素が文書のアウトラインにおいて一つのノードに格納されるということです。
以下のようにマークアップすれば:
<header>
<hgroup>
<h1>My Weblog</h1>
<h2>A lot of effort went into making this effortless.</h2>
</hgroup>
…
</header>
…
<div class="entry">
<h2>Travel day</h2>
</div>
…
<div class="entry">
<h2>I'm going to Prague!</h2>
</div>
文書のアウトラインは以下のように構築されます:
My Weblog (h1 of its hgroup) | +--Travel day (h2) | +--I'm going to Prague! (h2)
HTML5 Outlinerで自分の作成したウェブページが見出し要素を適切に利用しているかどうかをテストすることができます。
❧
題材としたページはまだまだ続きます。以下のようなマークアップはどうすることができるのでしょうか:
<div class="entry">
<p class="post-date">October 22, 2009</p>
<h2>
<a href="#"
rel="bookmark"
title="link to this post">
Travel day
</a>
</h2>
…
</div>
これもまた妥当なHTML5です。しかし、HTML5ではウェブページの記事をマークアップするのにもっと適当な要素が提供しています。それは<article>
要素です。
<article>
<p class="post-date">October 22, 2009</p>
<h2>
<a href="#"
rel="bookmark"
title="link to this post">
Travel day
</a>
</h2>
…
</article>
これではとてもシンプルとは言えませんね。他にもまだ変更するべき点はあります。変更後のソースを見てみてください。その後説明します:
<article>
<header>
<p class="post-date">October 22, 2009</p>
<h1>
<a href="#"
rel="bookmark"
title="link to this post">
Travel day
</a>
</h1>
</header>
…
</article>
わかるでしょうか?<h2>
要素を<h1<
にし、<header>
要素内に格納しています。<header>
については既に触れた通り、その役目は記事の見出し(この場合は記事のタイトルと発行日時)を構成する要素をまとめるというものです。いや、でも、しかし、<h1>
は文書ごとに一つだけではないんですか? 文書のアウトラインをめちゃくちゃにしてしまわないんですか? そういうことにはなりませんが、どうしてそうはならないかを理解するために、少し詳しく説明しましょう
HTML 4では文書のアウトラインを構築する事ができるのは<h1>
~<h6>
要素だけでした。アウトラインのルートノードを一つだけにしたい場合、<h1>
はマークアップの中で一つしか使うことができません。対してHTML5の仕様では文書のアウトラインを生成するためのアルゴリズムが定義されており、それにはHTML5の新しいセマンティックな要素が含まれています。HTML5のアルゴリズムでは<article>
要素は新しいセクション、つまり文書のアウトラインに新たなノードを作るということになっています。そしてHTML5ではセクションごとに<h1>
を持つことができます。
これはHTML 4から大きく変わった点ですが、なぜ良い変更なのかということを説明しましょう。多くのウェブページはある種のひな形(テンプレート)を使って制作されています。コンテンツの一部は様々な所から取ってくることになり、それらはウェブページのあちこちに挿入されます。多くのチュートリアルでは「このHTMLコードをコピーしてウェブページに貼り付けましょう」といった風に解説しているでしょう。ごく小さなコンテンツの場合はこれでも大丈夫でしょうが、セクション全体のマークアップを貼り付けるというような場合ではどうでしょうか? チュートリアルでは以下のように解説することになります: 「このHTMLコードをコピーし、エディタに貼り付け、挿入するウェブページに適合するように見出しのタグのレベルを修正しましょう」
別の言い方をすると、HTML 4では融通のきく見出し要素を持っていないということです。たった六つの数字付きの見出し要素、<h1>
~<h6>
、しかなく、その数字のままの順序でネストされないといけません。これでは、特にウェブページを「編集」ではなく「生成」している場合はたまりません。HTML5ではこの問題を新しいセクショニング要素と既存の見出し要素に関する新たなルールを設けることで解決しました。もし既に新しいセクショニング要素をウェブページで使用している場合:
<article>
<header>
<h1>A syndicated post</h1>
</header>
<p>Lorem ipsum blah blah…</p>
</article>
このコードをコピーして何も変更することなくウェブページのどこにでも貼り付けることができます。全体が<article>
で括られているので、<h1>
要素が含まれていることにまったく問題はありません。この場合<article>
要素は貼り付けられた文書のアウトラインのノードに新たなノードとして挿入され、<h1>
要素がそのノードのタイトルになり、元々そのウェブページにあった他のセクショニング要素は文書のアウトラインにおいてそれまでと同じ状態のまま残ります。
他のウェブ技術と同じく、現実にはもうちょっとややこしいです。新しい「明快な」セクショニング要素(<h1>
が含まれる<article>
)は古い「暗黙の」セクショニング要素(<h1>
~<h6>
それ自身)と組み合わせると思いもよらないことが起きてしまいます。両方ではなくどちらかを利用することによって簡潔にすることはできますが。どうしても同じウェブページで両方使わなくてはならない場合、HTML5 Outlinerでどういう結果になるかを確認した方が良いでしょう。
❧
興味をそそりますよね? 「エベレストで裸で星条旗よ永遠なれを歌いながら後ろ向きでスキーをする」などという意味での興味をそそるではなく、セマンティックなマークアップがどこまで進んでいるのかというような意味でです。では題材としているページの続きを見てみましょう。次に注目したいのは以下の通りです:
<div class="entry">
<p class="post-date">October 22, 2009</p>
<h2>Travel day</h2>
</div>
見飽きていますよね? よくあるパターン ― 記事の発行日時を指定する ― でまったくセマンティックなマークアップではなく、class
属性で何とかしようとしています。これもまた妥当なHTML5ではあります。変更することを要求されているわけではありません。しかしHTML5ではこのケースに使うことのできる<time>
要素が提供されます。
<time datetime="2009-10-22" pubdate>October 22, 2009</time>
<time>
は三つの部分に分けることができます:
pubdate
という任意のフラグこの例ではdatetime
属性には日付のみが含まれ、時刻は含まれていません、四桁の年と二桁の月、そして二桁の日が「-」で繋げられています:
<time datetime="2009-10-22" pubdate>October 22, 2009</time>
もし時刻も追加したい場合は、T
という文字を日付に続けて書き、その後に二十四時間表記で時刻、更に時差を書きます。
<time datetime="2009-10-22T13:59:47-04:00" pubdate>
October 22, 2009 1:59pm EDT
</time>
(この日付と時刻のフォーマットは非常に柔軟なものです。HTML5仕様には正しい日付と時刻の例も記載されています。)
テキスト部分 ― <time>
と</time>
の間にあるもの ― も、機械的に判断できる日付と時刻に合わせて変更したことに気をつけてください。必しもこうする必要があるというわけではありません。datetime
属性において機械的に判断できる日付と時刻さえきちんと書いていれば、テキスト部分はどう書いても構いません。つまり以下のように書いてもHTML5妥当だということになります:
<time datetime="2009-10-22">last Thursday</time>
またはこのように書いてもHTML5として妥当です:
<time datetime="2009-10-22"></time>
最後はpubdate
属性です。これは真偽値の属性で、必要な場合に以下のように追加するだけです:
<time datetime="2009-10-22" pubdate>October 22, 2009</time>
もし属性を「そのままで」書くのを好まないのなら、こう書いても構いません:
<time datetime="2009-10-22" pubdate="pubdate">October 22, 2009</time>
pubdate
属性はどんな意味を持つのでしょうか? この属性は二つの意味を持ちます。もし<time>
属性が<article>
要素の中にある場合、その記事の発行日時を意味し、もし<time>
が<article>
の中にはない場合、文書全体の発行日時を意味します。
それでは記事全体をHTML5を使って書きなおしてみましょう:
<article>
<header>
<time datetime="2009-10-22" pubdate>
October 22, 2009
</time>
<h1>
<a href="#"
rel="bookmark"
title="link to this post">
Travel day
</a>
</h1>
</header>
<p>Lorem ipsum dolor sit amet…</p>
</article>
❧
ナビゲーション・バーはウェブサイトの最も重要な部分の一つです。CNN.comでは「タブ」がそれぞれのウェブページにあり様々なニュースカテゴリ ― 「技術」、「健康」、「スポーツ」など ― にリンクしています。Googleの検索結果ページにも似たようなものがあり、Google別のサービス ― 「画像」、「動画」、「地図」など ― で同じ検索語によって検索しなおすことができるようになっています。例としたページにもナビゲーション・バーがヘッダーにあり、例として他のセクション ― 「ホーム」、「ブログ」、「ギャラリー」など ― へのリンクがあります。
ナビゲーション・バーは以下のようにマークアップされています:
<div id="nav">
<ul>
<li><a href="#">home</a></li>
<li><a href="#">blog</a></li>
<li><a href="#">gallery</a></li>
<li><a href="#">about</a></li>
</ul>
</div>
もちろんこれも妥当なHTML5です。リストとして四つの項目がマークアップされていますが、それがウェブサイトのナビゲーションであることは教えてくれません。ヘッダーの一部になっていたり、リンクの文字列から視覚的に類推することはできますが、セマンティクス的には他のリンクのリストと何ら変わりはないものです。
誰がウェブサイトのナビゲーションのセマンティクスを気にかけるのでしょうか? 例えば障害を持つ人々です。なぜでしょうか? 以下のような状況を考えてみてください: 手足の動きが制限されていてマウスを使うことが難しいなら、その補助のためにメインのナビゲーションを辿る(または戻る)ためにブラウザの拡張を使うでしょう。または次のような状況も考えてみてください: 視覚に障害を持つ場合、「音声読み上げソフトウェア」と呼ばれる文章を読み上げてウェブページを要約してくれるものを使うのではないでしょうか。ウェブページのタイトルの次に大切なのはメインのナビゲーションのリンクについての情報です。迅速にサイト内を辿って欲しい場合、ナビゲーション・バーにすぐジャンプできるように音声読み上げソフトウェアに教えてやる必要があるでしょう。また本文をすぐに読んで欲しい場合は、ナビゲーション・バーを飛ばしてコンテンツ本文をすぐ読み上げるよう音声読み上げソフトウェアに伝える必要があるでしょう。いずれにせよナビゲーションのリンクを機械的に特定できるようにすることが重要です。
つまり<div id="nav">
とウェブサイトのナビゲーションをマークアップすることに何も間違いはありませんが、正しいというわけでもありません。悪くはないという程度のものです。HTML5ではナビゲーションのセクションをセマンティックにマークアップするために<nav>
要素が提供されています。
<nav>
<ul>
<li><a href="#">home</a></li>
<li><a href="#">blog</a></li>
<li><a href="#">gallery</a></li>
<li><a href="#">about</a></li>
</ul>
</nav>
質問: 本文へジャンプ(skip links)は<nav>
要素と互換性があるのですか? それとも今まで通りHTML5においても本文へジャンプするリンクが必要なのでしょうか?
答え: 本文へジャンプは読み上げソフトウェアにナビゲーションのセクションを読み飛ばすことができるようにするものです。これはサードパーティ製のソフトウェアを使ってマウスを使わずにウェブサイトを閲覧している障害のある人々の大いに助けになるものです(どうやって、そしてどうして本文へジャンプを提供するのか)。
音声読み上げソフトウェアが更新され<nav>
要素を認識するようになったら、<nav>
要素でマークアップされたナビゲーションのセクションを飛ばすかどうかを自動的に尋ねることができるであろうと思われるので、本文へジャンプは不必要になるでしょう。しかし、HTML5に対応した音声読み上げソフトウェアに全ての障害のある人々が更新するまでにはまだまだ時間がかかるでしょうから、<nav>
セクションを飛ばすための本文へジャンプを続けて提供すべきでしょう。
❧
ようやく題材としたページの最後に辿り着きました。最後にお話しすることはウェブページの最後にあるもの、つまりフッターです。フッターは以下のようにマークアップされています:
<div id="footer">
<p>§</p>
<p>© 2001–9 <a href="#">Mark Pilgrim</a></p>
</div>
妥当なHTML5ですね。もちろんこのままでも結構ですが、HTML5ではより適切な<footer>
要素が提供されています。
<footer>
<p>§</p>
<p>© 2001–9 <a href="#">Mark Pilgrim</a></p>
</footer>
<footer>
要素としてふさわしいのはどんなものでしょうか? おそらくあなたが今<div id="footer">
にいれているものがそうでしょう。これは何度も繰り返された質問ですが、そうとしか言えません。HTML5仕様では「フッターは通常セクションについて誰が書いたのかや関連した文書はあるか、著作権情報などについての情報を格納する」としています。例のページでもそうなっていますね: 短い著作権情報についての表明文と製作者についてのウェブページへのリンクから成っています。有名なサイトをいくつか見てみれば、フッターにどういうものが含まれるのかわかるでしょう。
<footer>
にふさわしいものです。<footer>
で括ることができます。<footer>
要素にふさわしいものです(ただし、それらのリンクはナビゲーションではなく他のウェブサイトにあるプロジェクトへの単なるリンクの集合に過ぎないので<nav>
要素で括るべきではありません)。最近「Fat footers」は爆発的に流行しています。W3Cのウェブサイトを見てみてください。三つのカラムに分けられて、「Navigation」、「Contact W3C」、そして「W3C Updates」とあります。これのマークアップは以下のような感じになっています:
<div id="w3c_footer">
<div class="w3c_footer-nav">
<h3>Navigation</h3>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/standards/">Standards</a></li>
<li><a href="/participate/">Participate</a></li>
<li><a href="/Consortium/membership">Membership</a></li>
<li><a href="/Consortium/">About W3C</a></li>
</ul>
</div>
<div class="w3c_footer-nav">
<h3>Contact W3C</h3>
<ul>
<li><a href="/Consortium/contact">Contact</a></li>
<li><a href="/Help/">Help and FAQ</a></li>
<li><a href="/Consortium/sup">Donate</a></li>
<li><a href="/Consortium/siteindex">Site Map</a></li>
</ul>
</div>
<div class="w3c_footer-nav">
<h3>W3C Updates</h3>
<ul>
<li><a href="http://twitter.com/W3C">Twitter</a></li>
<li><a href="http://identi.ca/w3c">Identi.ca</a></li>
</ul>
</div>
<p class="copyright">Copyright © 2009 W3C</p>
</div>
セマンティックなHTML5に変換するためには以下のような変更を加えます:
<div id="w3c_footer">
を<footer>
要素に変換する。<div class="w3c_footer-nav">
を<nav>
要素に変換し、三つ目は<section>
要素に変換する。<h3>
の見出しを<h1>
に変換し、セクショニング要素内に入るようにする。<nav>
要素は<article>
要素と同じように文書のアウトラインにセクションを作成します。最終的にマークアップは以下のようになります:
<footer>
<nav>
<h1>Navigation</h1>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/standards/">Standards</a></li>
<li><a href="/participate/">Participate</a></li>
<li><a href="/Consortium/membership">Membership</a></li>
<li><a href="/Consortium/">About W3C</a></li>
</ul>
</nav>
<nav>
<h1>Contact W3C</h1>
<ul>
<li><a href="/Consortium/contact">Contact</a></li>
<li><a href="/Help/">Help and FAQ</a></li>
<li><a href="/Consortium/sup">Donate</a></li>
<li><a href="/Consortium/siteindex">Site Map</a></li>
</ul>
</nav>
<section>
<h1>W3C Updates</h1>
<ul>
<li><a href="http://twitter.com/W3C">Twitter</a></li>
<li><a href="http://identi.ca/w3c">Identi.ca</a></li>
</ul>
</section>
<p class="copyright">Copyright © 2009 W3C</p>
</footer>
❧
このページで題材としたウェブページ:
文字エンコーディングについて:
HTML5の新しい要素をInternet Explorerで有効にする方法について:
標準モードとdoctype判別について:
HTML5対応検証ツール:
❧
Copyright MMIX–MMX Mark Pilgrim, Kyo Nagashima
❧
このドキュメントはWhat Does It All Mean? - Dive Into HTML5の日本語訳であり、元のドキュメントと同じくCC-BY-3.0の元で公開されています。