入門 HTML5 読書ノート

読者ノート

なにぶん古い図書なので、

  • リンク切れの URL は可能な範囲で更新する（無意味かもしれない）。

  • Internet Explorer に関する記述は無視する。

著者:

Mark Pilgrim

訳者:

水原文

監訳者:

矢倉眞隆

出版社:

オライリー・ジャパン

発行年:

2011 年

ISBN:

978-4-87311-482-8

監訳者まえがき

この書籍の概要は次のとおり：

本書『入門 HTML5』は、Google で Developer Advocate を務める Mark Pilgrim による HTML5 と周辺技術の書籍『HTML5: Up and Runing』の日本語訳になります。

Developer Center で Developer Advocate なる役職の一覧が確認できる。役割の詳細もそこに述べられている。

この原著、その原稿やデモすべてが Creative Commons の Attribution ライセンスのもと、Dive Into HTML5 というサイトで公開されています。

ということは、紙の本から読書ノートを綴らなくとも、つねに最新版である原稿を公開している上記サイトを読めば良かったかもしれない。

まえがき

本書で焦点が当たるトピックが箇条書きになっている。本ノートの見通しをよくするためにも控えておく：

  • <header>, <footer>, そして <section> などの新たな意味要素 (3 章)

  • JavaScript でプログラム可能な二次元の図形描画機能、Canvas (4 章)

  • サードパーティ製プラグインの助けを借りずに Web へ埋め込み可能なビデオ (5 章)

  • Web アプリケーションへ、自分の居る位置を通知できる位置情報通知機能 (6 章)

  • サードパーティ製プラグインを必要としない永続的ローカルストレージ (7 章)

  • ネットワークアクセスが切断された後でも動作可能なオフライン Web アプリケーション (8 章)

  • 改良された HTML フォーム (9 章)

  • HTML5 にはない語彙を作成し、Web ページに独自の意味づけが可能なマイクロデータ

個人的に興味があるのは第 3, 4, 9 章だ。ビデオ編集する習慣があることから第 5 章も参考になる。

1 章 ここまでの道のり

著者が《心の片隅に留めておいて欲しい》という言葉をほぼ引用しておく：

実装と詳細の間には、微妙な関係を保つ必要がある。使用が完成する前に実装が行われることは望ましくない。なぜならば、既存の実装の詳細に引きずられ、仕様が制約されてしまうからだ。しかし、実装されたものが利用されないまま仕様が完成することもまた望ましくない。なぜならば、利用者からのフィードバックが必要だからだ。

実装と詳細は、一方が「主」で他方が「従」ということではないということか。

この後は読み物のようなテキストが続く。WHATWG の誕生くらいまで読み流す感じでいい。

十年に及ぶ HTML への投資を無駄にし、また既存 Web ページの 99 パーセントを使えなくする代わりに、WHATWG は別のアプローチを取ることにした。ブラウザが実際に利用している「寛大な」エラー処理アルゴリズムを文書化することだ。

これは解析だ。

そして、2006 年 10 月、ついに W3C の創設者である Tim Berners-Lee が、HTML の進化のために W3C が WHATWG と経堂で作業を進めることを発表した。

和解のようなものと考えられる。なお、W3C という用語は、私の読み抜けがなければ、何の説明もなしに本文に登場した。

再設立され、生まれ変わった W3C HTML ワーキンググループが最初に行った決定のひとつは、「Web Application 1.0」を「HTML5」と改名することだった。

引用しなかったが、Web Application 1.0 とは解析作業と並行して進行していたキャンバス、ビデオサポート等のドラフトだ。

2 章 HTML5 の機能を検出する

HTML5 はひとつの大きなものではなく、個別の機能が集まったものなのだ。

したがって、例えば「キャンバスは対応済みか？」「ビデオは対応済みか？」などを調べることをこの章では検討していく。

ブラウザが特定の機能をサポートしているかどうかを検出するための、基本的なテクニックは 4 つある。

本文の技法一覧を単純化して列挙しておく：

  1. window や navigator グローバルオブジェクトに対して、特定のプロパティーが存在するかを調べる。

  2. new した要素に対して特定のプロパティーが存在するかを調べる。

  3. new した要素に対して特定のメソッドが存在するかを調べる。それを呼び出して戻り値を調べる。

  4. new した要素に対してプロパティーを特定の値に設定し、それが値を保持しているかを調べる。

以上は、当然ながら JavaScript コードを走らせて検出する。

Modernzir は、オープンソースで MIT ライセンスの、数多くの HTML5 と CSS3 機能のサポートを検出してくれる JavaScript ライブラリだ。

この JS ファイルをローカルに用意して <head> 内から <script> で読み込ませれば利用可能になる。オブジェクト Modernizr にブラウザーが特定の機能に対応しているかどうかを示すフラグを持っている。例えばキャンバスを使いたければ真偽値 Modernizr.canvas を調べるという具合だ。本章はこのように、個別機能と検出方法紹介を並べる構造になっているが、本ノートでは割愛する。現代的ブラウザーではどうせ対応されているので。

ブラウザが HTML5 ビデオをサポートしていない場合には、<video> 要素として作成された DOM オブジェクトは共通プロパティのみを持っているはずだ。

この考え方はビデオ以外の HTML5 新機能についても成り立つ。興味があるので、ビデオに関する記述を中心に引用する。

「コーデック」を次のように定義している：

ビデオをビットストリームへエンコードする際に使われるアルゴリズムのことだ。

先程の判定論理の「裏」が述べられる：

ブラウザが HTML5 ビデオをサポートしていれば、<video> 要素として作成された DOM オブジェクトは canPlayType() メソッドを持っているはずだ。

ローカルストレージの節の冒頭：

HTML5 のストレージは、ウェブサイトがコンピュータに情報を保存して後で使うための手段を提供する。概念としてはクッキーに似ているが、より大きな情報量を取り扱えるように設計されている。

本書の後半で一章割いて説明される。

本書では「マークアップ教授に質問」という質問と回答形式の囲み記事が随所に現れる。次の概念は重要なので引用する：

ブラウザの中では、どの Web サイトも自信が保存した値を読んだり変更したりできるが、別のサイトが保存した値へのアクセスはできない。このことは、同一生成元制約 (same-origin restriction) と呼ばれている。

<input> 要素の type 属性になり得る値が HTML5 で急増したことが述べられている。他にも、

プレースホルダは、そのフィールドが空で、かつそこにフォーカスがない場合に入力フィールド中に表示される

機能がある。また、フォーカスに関しては、

HTML5 はすべてのフォームコントロールに autofocus 属性を導入した。この autofocus 属性は、フォーカスを特定のフィールドへ移動するという、文字通りの働きをする。

最後に、聞き馴染みのない機能を知る：

マイクロデータは、Web ページに意味付けを追加するための標準的な方法だ。例えば、マイクロデータを使ってある写真が特定のクリエイティブコモンズライセンスで利用できることを宣言できる。

3 章 HTML 文書の構造と意味付け

この章では XHTML 1.0 文書を HTML5 に改良していくという実践的なものだ。以前、自作の古いページを書き直す時にこの記述を大いに利用した。サンプルページはこれ： <http://diveintohtml5.info/examples/blog-original.html>

少なくとも一度は「ソースを表示」してみてから、この先を読み進めて欲しい。

当該 HTML を画面に表示しながら本章を読んでもいい。

DOCTYPE の記述は単純に済ませるのが HTML5 だ：

これがその、HTML5 の DOCTYPE だ。

<!DOCTYPE html>

これだけ。だった 15 文字だ。手で打つのも簡単だし、間違えることもないだろう。

VS Code でコードを編集するのであれば補完候補に現れるからさらに楽だ。

DOCTYPE は、HTML ファイルの最初の行に存在する必要がある。

次にルート要素である <html> を改良している。やはり単純だ。

  • xmlns 属性は必要ない。

  • lang 属性があれは xml:lang 属性は不要だ。

どうも HTML ファイルの先頭から末尾に向かって改良しているらしい。次は <head> に着手。

ルート要素の最初の子要素は、普通 <head> 要素だ。

文字エンコーディングの宣言を書き換える：

実は、HTML5 ではその（引用註：<meta> タグ）使い方も少しやさしくなっている。以下のように書けるのだ。

<meta charset="utf-8" />

これは、すべてのブラウザで動作する。

マークアップ教授と著者から共通する警告：

すべての HTML 文書には 常に 文字エンコーディングを指定すべきであり、そうしないといろいろとまずいことが起こるだろう。（略）どの方法でもいいから確実に行ってほしい。

個人的に軽視していた <link> タグについての記述が参考になる。

リンクタイプは、別のページを参照する 理由 を説明するためのものだ。「私がここで別のページを参照しているそのわけは…」に続く文章を作っていると考えればよい。

HTML5 はリンクによる関連付けを二つに区分しているとして、次の記述を引用している：

Two categories of links can be created using the link element: links to external resources and hyperlinks. （略） The exact behavior for links to external resources depends on the exact relationship, as defined for the relevant link type. (<https://html.spec.whatwg.org/multipage/semantics.html#attr-link-rel>)

サンプルページでは CSS ファイルに関する <link> だけが外部リソースへのリンクに当てはまるとある。

<meta rel="archives" ...> をブログの過去記事索引に使えるとある。後で試したい。総索引ページにこのタグを書く感じか。

HTML5 の新しい意味要素として pp. 45-46 に列挙されているもののほとんどが改良作業で重要だ。

すべてのブラウザは不明な要素をインラインレベル要素として表示する。

ので、

HTML5 の新しい要素のいくつかは、ブロックレベル要素として定義されている

ものを旧式ブラウザーで描画させようとすると、明らかにおかしくなる。CSS による回避策が本書に与えられている。

<div id="header"> のようなブロックが文書にあれば、それを <header> に置き換えることを検討する価値がある：

HTML5 では、<header> 要素がこの目的のために定義されている。

HTML4 では、文書のアウトラインを作成する方法が <h1> ～ <h6> だけ しかなかった。

ワープロソフトの類比から、そういうものだと思っていた。

<hgroup> 要素は、二個またはそれ以上の 関連する 見出し要素をグループ化する働きをする。ここで「関連する」とは、全体として文書アウトライン中で単一のノードを形成するという意味だ。

見本コードを確認すると <hgroup> の中に <h1>, <h2> がこの順序で現れている。<hgroup> を抜けると、個別の <h2> が現れる。

HTML5 <article> 要素は、部分文書を構成すると私には読める。

この HTML5 のアルゴリズム（引用註：新しい意味要素を採用した文書アウトライン生成アルゴリズム）では、<article> 要素は新しいセクション、つまり新しいノードを文書アウトラインに生成することになっている。そして HTML5 では、セクションごとに <h1> 要素が持てるのだ。

このおかげで見出し番号を気にすることなく <article> ノード部分をコピーペースト可能になった。

日付と時間を表現するための新しい要素を紹介している：

<time> 要素は、三つの部分に分けられる。

  • 機械可読なタイムスタンプ

  • 人間が読むためのテキスト

  • オプションの pubdate フラグ

第一項目は datetime 属性値に記すようだ。第二項目が要素の値で、空であってもかまわないらしい。それどころか《テキストは何でもよいのだ》。

この pubdate 属性の意味するところは、以下の二つのどちらかだ。まず <time> 要素が <article> 要素の中にある場合、このタイムスタンプはその記事が公開された日付であることを意味する。また <time> 要素が <article> 要素の中にない場合、このタイムスタンプは文書が公開された日付であることを意味する。

この仕様ならばブログ型のページ、特に検索結果ページを作りやすくなるだろう。

HTML5 では、ナビゲーションのセクションをマークアップするための意味的な方法が用意されている。それが、<nav> 要素だ。

<div id="nav"> 区画を <nav> に自然に置き換える。

<footer> 要素を使うのにふさわしい場所はどこだろうか。おそらく、現在 <div id="footer"> としている場所すべてだろう。

4 章 Canvas による描画

WebGL をやったことがあるので <canvas> 要素は馴染みがある。この章の内容をその理解の確認に使える。

HTML5 は <canvas> を「解像度に依存するビットマップ描画機能で、グラフ、ゲームのグラフィックス、あるいはその他のビジュアル画像をオンザフライで表示できる」と定義している。

飛行中で表示できるとは何だという疑問が湧く。この先を読むことで明らかになる。

Canvas そのものは目には見えない。<canvas> 要素自身は何の内容も持たず、またボーダーも指定されていないからだ。

この事実は WebGL のコードを書きまくったときに体で知った。

JavaScript コードを書く。DOM 中の <canvas> 要素が document から得られたとする。描画をするに当たって最初にすることは、

その getContext() メソッドを呼び出す。getContext() メソッドには、 必ず 文字列 "2d" を渡さなくてはならない。

WebGL 描画の場合には "webgl" を渡さなくてはならない。次のページ (p. 67) の脚注によると、本書発行時には仕様策定中だったらしい。

平面図形については Win32 GDI を扱う感覚で、図形に対応するメソッドを呼び出す。

  • .fillStyle

  • .fillRect(x, y, width, height)

  • .strokeStyle

  • .strokeRect(x, y, width, height)

  • .clearRect(x, y, width, height)

キャンバスの座標系はスクリーン座標系と同じ向きだ：

座標 (0, 0) は Canvas の左上隅に対応する。X 軸の値は、Canvas の右側に近づくにしたがって増加する。Y 軸の値は、Canvas の下端に近づくにしたがって増加する。

パスの考え方も Win32 GDI と同様だ。

  • .beginPath()

  • .moveTo(x, y)

  • .lineTo(x, y)

  • .stroke()

本書は鉛筆メソッドとインクメソッドという術語でコンテキストのメソッドの働きを上手く説明している。

テキスト描画のインターフェイスも Win32 GDI に似ている。描画コンテキストを介してフォント属性を操作する。

  • .font

  • .textAlign

  • .textBaseline

  • .fillText(text, x, y)

  • .strokeText(text, x, y)

円を描く方法については後で説明するが、ここではちょっとずるをして矩形を描いて済ませることにしよう。

寸法の小さい矩形を描けば、遠目からは円に見える。

シェープや線は単色以外で描くこともできる。グラデーションを使えば、いろいろな効果が楽しめる。

次の二つのメソッドがグラデーション塗りを実現するものだ。放射状版は同心円でなくてもいいとは：

  • .createLinearGradient(x0, y0, x1, y0)

  • .createRadialGradient(x0, y0, r0, x1, y1, r1)

これらの戻り値のプロパティーに対して色指定を行う。

  • .addColorStop(offset, color): offset は 0..1 の値で指定。

グラデーションは対象図形に設定しなければ意味がない。

グラデーションを描くには、fillStyle をグラデーションに設定し、矩形や直線などのシェープを描けばよい。

画像をキャンバスに描く方法。JavaScript で画像を取り扱う場合、キャンバスが関係しなくても使えるコードを含む。

Canvas に画像を描くには、まず画像が必要だ。画像は既存の <img> 要素でもいいし、JavaScript を使って作成した Image() オブジェクトでもよい。

本書 p. 81 と p.82 それぞれのコード片の構造を頭に叩き込め。より現代的なコードを目にすることがあり、これがその基本形だ。

Halma 実装例に目を通す。キャンバスモノでよくある、マウスクリック位置を検出する課題に関するコツを知る：

実は、マウスイベントはブラウザによって異なる実装がされているので、これはなかなか難しいことなのだ。

（略）

「マウスクリック」→「文書の相対座標」→「Canvas 相対座標」→「アプリケーション特有のコード」という流れになることは覚えておいてほしい。

コードを見ると、参照する可能性がある値は次だ：

  • マウスイベント .pageX, .pageY

  • マウスイベント .clientX, .clientY

  • 文書本文 .scrollLeft, .scrollTop

  • ルート要素 .scrollLeft, .scrollTop

  • キャンバス .offsetLeft, .offsetTop

5 章 Web のビデオ

この章の記述は HTML5 というより、ビデオファイルの解説がありがたい。

HTML5 では、<video> 要素を使って Web ページにビデオを埋め込む標準的な方法が定義されている。

そのタグについての詳細を説明する準備として、ビデオファイルの構造に関する解説が先だ。

実は、「AVI」や「MP4」はコンテナフォーマットに過ぎないのだ。ZIP ファイルがどんな種類のファイルでも圧縮できるように、コンテナフォーマットはその中にデータを格納する 方法 を定義しているだけで、データの 種類 については規定していない。

VLC はいいソフトなのでインストールしておきたい。

ビデオコーデック とは、ビデオストリームがエンコードされる際に使われるアルゴリズムのことだ。（「コーデック (codec)」とは「コーダ (coder)」と「デコーダ (decoder)」の合成語だ。）

FFmpeg 操作時には世話になっている H.264 だが、

H.264 標準は、特許に縛られている。

ビデオにはない概念がオーディオにはある。それは チャンネル だ。

モノラルならば一チャンネル、ステレオならば二チャンネルというアレだ。

ひとつひとつのスピーカーは、録音された特定の チャンネル を再生する。

スピーカーの数がチャンネル数よりも多い場合に、スピーカーそれぞれ、どのチャンネルを担当するのかが気になる。

MP3 は、音のチャンネルを 二個 まで持てる。

モノラルかステレオしかあり得ない。チャンネルなしの可能性もない。

音質とビットレートとは線形比例するわけではない。

映像でも同じことが言えるはずだ。

MP3 フォーマット（1991 年に標準化）は特許に縛られている。

これまた FFmpeg 操作時に世話になっている AAC だが、

AAC フォーマットは特許に縛られている。

値段を調べたければ License Fees を当たる。

AAC は音声チャンネルを 48 個まで エンコードできるが、実際に試した人は誰もいないだろう。

ここまで映像と音声の符号形式を多数紹介したのは、<video> 要素の書き方に関する説明を読者に理解させるための準備だとわかる。

ひとつの <video> 要素は複数のビデオファイルにリンクすることができ、ブラウザは自分が再生可能な最初のビデオファイルを選択する。どのブラウザがど のコンテナやコーデックをサポートしているかどうかを理解するのは、あなたの責任 なのだ。

ブラウザーは <video> タグ自体には対応しているが、どんな形式（側面が上記の二つあることに注意）のビデオファイルでも再生可能であるという意味ではない。

ビデオ変換ツールの記述 (pp. 102-124) は今は読み飛ばす。私は FFmpeg しか使わない。

<canvas> とは違い、

ブラウザは <video> タグで指定したボックス内の中央にビデオを表示してくれる。勝手に比率が変更されて、つぶれたり引き伸ばされたりすることはない。

デフォルトでは <video> 要素は再生コントロールの類を何も提供しない。（略）

自分でインタフェースを作るつもりがなければ、ブラウザに組み込みのコントロールを表示させることもできる。これを行うには、<video> タグに control 属性を追加するだけでよい。

ブラウザーにもよるのだろうが、組み込みのコントローラーは YouTube のそれに比較すると機能が貧弱でありがちだ。

<video> 要素には子ノードとしてビデオファイル一つを指す <source> 要素を通常持つ。同一内容のビデオファイルを複数用意しておいて、それぞれに対応する <source> 要素を併記する。

もしブラウザに前もってビデオの形式を教えておくことができれば、ネットワークトラフィックを大幅に節約できる。これは、<source> 要素の type 属性を使って行う。

子要素 <source> の記載順序は重要だ：

ブラウザがそのビデオを再生できないと判断したら、そのファイルはダウン ロードしない。

本章の内容を総合したコマンドライン、HTML および JavaScript コードで締めくくられる。ここまで手間をかけてでも公に見てもらいたいビデオなどは当面のところ持ち合わせていないので、理屈を理解できればこの章は十分とする。

6 章 Geolocation API による位置情報通知

Geolocation （位置情報通知機能）は、あなたが地球上のどこにいるかを調べる機能で、そしてその情報をあなたの信頼する人々に知らせることができる。位置の検出には、いろいろな方法がある。いくつか例を挙げれば、IP アドレス、無線ネットワークへの接続状況、携帯電話が通信している基地局、あるいは人工衛星からの緯度・経度を受信する GPS ハードウェアなどだ。

本書表 6-1 によると、現代的ブラウザー全てが Geolocation API に対応している。利用可能性は、むしろ地理的な条件によるほうが大きい？

Geolocation API は、navigation オブジェクトの navigator.geolocation という新しいプロパティを利用する。

本文では .getCurrentPosition(success) から説明が始める。コールバックを引数に取る。このコールバック関数が呼び出されるタイミングはわからないと思っているのがいいようだ。

エラー処理用コールバックは getCurrentPosition の第二引数に与えることが可能。

一部のモバイル機器は、あなたがいる位置を検出するのに 二通りの 方法をサポートしている。

これらの方法は精度が異なる。用途によって使い分けたり、両者を組み合わせたりする。

geo.js は W3C の Geolocation API や Gears の API, そして各種のモバイルプラットフォームの提供する API の違いを吸収してくれる、MIT のもとライセンスされたオープンソースの JavaScript ライブラリだ。

このライブラリーは <script> タグを二つ要する。ページロード時間を考慮すれば、これらのタグを <head> に書かないほうがいいと著者は述べている。

総合的な実例の節では生の Geolocation API ではなく geo.js を採用。

7 章 Web アプリケーションのローカルストレージ：その過去・現在・未来

Web アプリケーションには、デスクトップアプリケーションのような設定保存の仕組みがなかった。

Cookie にはローカルストレージとして利用するには欠点がある。

Cookie は HTTP 要求すべてに含まれてしまい、送受信が重複したり暗号化がなされないこと、データ要領に 4KB 制限があることが弱点だという。

  • Internet Explorer の userData,

  • Adobe の Flash Cookie,

  • Brad Neuberg の AMASS および dojox.storage,

  • Google Gears

などのデータ保存機能を考察し、次のように総括している：

これらのソリューションを振り返ってみると、ひとつのパターンが浮かび上がる。全て特定のブラウザに特有の機能か、またはサードパーティのプラグインに依存するのだ。

ここから HTML5 が解決するべき問題が：

サードパーティのプラグインに依存することなく、複数のブラウザでネイティブかつ統一的に実装された、標準的な API を提供すること

だとなる。

本節では Web Storage のことを HTML5 ストレージと呼称している。

Web ページがクライアント Web ブラウザの中から、キーと値のペアに名前を付けてローカルに保存するための方法だ。Cookie に保存されるデータと同様に、このデータはその Web サイトを離れたり、ブラウザタブを閉じたり、ブラウザを終了したり、その他どんなことをした後でも保持される。しかし Cookie とは違って、このデータはリモートの Web サーバへ送信されることはない（わざわざ手作業で送信しようとしない限りは）。

この機能はどのブラウザーのほとんどの最新版で利用可能だ。

JavaScript のコードからは、window オブジェクト上の localStorage オブジェクトを介して HTML5 ストレージへアクセスする。

HTML5 ストレージは、名前付きキーと値のペアを基本としている。

データベースでいうと MongoDB とか DynamoDB のような感じだろうか。しかし：

データは実際には文字列として保存される。文字列以外を保存して取り出そうとする場合には、parseInt() や parseFloat() などの関数を使って取り出したデータを元の JavaScript データ型へ型変換する必要があるのだ。

ストレージ領域が変化したことをプログラムから検出したければ、storage イベントをトラップすればよい。

すなわち、

window.addEventListener("storage", handle_storage, false);

function handle_storage(e){
    // ...
}

「5MB」とは、生成元ごとにストレージ領域が持てるデフォルトの要領だ。

ここで言う生成元とは same-origin restriction などの術語中に含まれる origin と同じ概念だ。

QUOTA_EXCEEDED_ERR とは、5MB のストレージの制限を超えた場合に発生する例外だ。

実例として、第四章の Halma ゲームにステートセーブ機能を実装している。

最後に、Web SQL Database と Indexed Database API という仕様について触れている。

8 章 オフライン状態での動作

定義から始まる：

最も単純なオフライン Web アプリケーションは、HTML, CSS, あるいは JavaScript ファイル、画像、もしくはその他の種類のリソースを指し示す URL のリストに過ぎない。オフライン Web アプリケーションのホームページは、マニフェストファイル と呼ばれるこのリストを参照している。

この一覧がサーバーの《どこか別のところにある》ことに注意。

オフライン Web アプリケーションは、キャッシュマニフェストファイルを中心として動作する。（略）これらのリソースをダウンロードしキャッシュするプロセスを開始させるには、<html> 要素の manifest 属性を使ってマニフェストファイルを指定する必要がある。

<!DOCTYPE html>
<html manifest="/cache.manifest">
<body>
...
</body>
</html>

キャッシュマニフェストファイルは Web サーバーのどこに置いてもよいが、MIME タイプ text/cache-manifest を使って送信されなくてはならない。

動作確認にはまたぞろローカルサーバーを稼動させる必要がある。

以下、マニフェストファイルの構成について記述されている。簡単に言うと次のようなものらしい：

  • 最初の行

  • 明示リスト区画

  • 代替区画

  • オンライン指定区画

最初の行は CACHE MANIFEST と書かれているだけだ。

「明示リスト」セクションの中のリソースはダウンロードされてローカルにキャッシュされ、ネットワークから切断されている間はいつでもオンラインのファイルの代わりに使われる。

オンライン指定区画の説明から：

NETWORK: の行が「オンライン指定リスト」セクションの始まりを示している。

この一覧に含まれるファイルはキャッシュされない。オフラインで利用不能。

CACHE: の行は「明示リスト」セクションの始まりを示している。

セクションラベルのないファイルリストは明示リストとみなされる。

代替区画の説明が他よりも長い。

FALLBACK セクションでは、オンラインリソースが何らかの理由でキャッシュできない場合、あるいはキャッシュに失敗した場合の代替リソースを指定できる。

HTML5 仕様から引用したらしい例を示したうえで：

CACHE MANIFEST
FALLBACK:
/ /offline.html
NETWORK:
*

その意味を解説している。

/ /offline.html の最初の一文字 / は URL ではなく、

ホームページだけではなく、サイトのすべてのページにマッチする。

NETWORK 区画の米印は

「オンライン指定リストのワイルドカードフラグ」と呼ばれ、インターネットに接続している限り、AppCache にないページは元の Web アドレスからダウンロードしてよい、という意味になる。

デバッグ手法については急所が二点あるそうだ。

たとえ一個でも、キャッシュマニフェストファイルのリストに記載されたリ ソースがダウンロードに失敗すれば、オフライン Web アプリケーションをキャッシュ するというプロセス全体が失敗してしまう。

もう一点はブラウザーのバグと錯覚するような現象がありがちだということだ。いろいろとすっ飛ばして結論だけノートする：

したがって、絶対にやっておくべきことがひとつある。Web サーバの設定を変更して、キャッシュマニフェストファイルが HTTP によってキャッシュされないようにしておくことだ。

さらに次の助言がある：

オフライン Web アプリケーションのリソースのどれかを変更したら、必ずキャッシュマニフェストファイル自身も変更しなくてはならない。

本文の記述の感じからすると、ほんとうに内容を変更する必要があると読める。単なる touch では不十分のようだ。

これは演習が難しい。ローカルホストではダウンロードの発生有無を検出できないのではないか。ブラウザーの開発ツールに送受信監視ビューでもあればいけるか？

9 章 Web フォーム

HTML5 では、フォーム中に使える入力形式が多数定義されている

主旨は <input type="xxxxxx"> の xxxxxx に指定可能な値が多数追加されたということだ。

HTML5 で Web フォームに行われた最初の改良は、入力フィールドにプレースホルダを設定する機能だ。

MFC の CEdit::SetCueBanner のような働きをする。やりかたは例えば <input placeholder="prompt-text"> のようにする。

自動フォーカスに関する記述。この機能がつねに便利であるとは限らないと述べる。特に、JavaScript でこの機能を実装してしまうと次のようなことがあり得る：

例えばページをスクロールしようとしてスペースバーを押しても、フォーカスがすでにフォームの入力フィールドにあるため、ページはスクロールせず、代わりにそのフィールドにスペースが入力されてしまう。

HTML5 の autofocus 属性を採用すると改善される：

この autofocus 属性は、ページのロードが完了した時点でフォーカスを特定の入力フィールドへ移動する

やり方は <input> 要素に属性 autofocus を追加すればいい。値は不要。

古いブラウザーは無視して、自動フォーカスを与えるならば autofocus しか使わないようにするのが良さそうだ。

HTML5 では、メールアドレス入力欄に対する <input> 要素にて属性 type="email" を指定する。ブラウザーによっては、専用の処理を行うことがあると言う：

Apple は、非情に賢い機能を iPhone の Web ブラウザに実装した。いくつかの新しい HTML5 入力形式を認識し、そして入力の種類に応じて 動的にオンスクリー ンキーボードを変更する という機能だ。

メールアドレス入力に特化したキーボード GUI を表示するようだ。

URL 入力欄に対する <input> 要素には属性 type="url" を与える。例えば iPhone4 では：

電子メールアドレスフィールドと同じ用に、iPhone では Web アドレスの入力に適した特別な仮想キーボードが表示される。スペースバーは消え、代わりにピリオド、スラッシュ、そして .com ボタンが表示される。.com ボタンを長押しすると、.co.jp や .jp などのよく使われるサフィックスを選ぶことができる。

数値入力用のコントロールにはスピンボックスとスライダーを用意できる。前者は MFC の CSpinEdit と同じ機能を期待してよい。

<input type="number"
       min="0"
       max="10"
       step="2"
       value="6">

ガワに加えて JavaScript による値操作も可能だ。例えば .stepUp(n) メソッドで入力欄の値が n 増加する。数値を得るには .valueAsNumber プロパティーを参照するといい。

後者は MFC でいう CSpinCtrl に相当する機能を設けたものだ。<input> 要素の属性では type="range" とする。

カレンダーや時計のような GUI から日付と時刻の一方または両方を選ぶためのフォーム要素が HTML5 で新しく追加された。タイミングの水準に対応して <input> 要素の type 属性に取る値が用意されている：

  • type="date"

  • type="month"

  • type="week"

  • type="time"

  • type="datetime-local"

本書で記載のある type="datetime" は現在廃止済みのようだ。また、本書執筆時点では Opera しかまともに対応していなかったらしく、そのせいか入力値を得る方法に関する記述がない。.value か .valueAsNumber が使える。後者はタイムスタンプを表現する数値だ。

検索欄は type="search" だ。

type="search" ボックスに実際に入力をし始めると、Safari はそのボックスの右側に小さな x ボタンを表示する。この x ボタンをクリックすると、フィールドの内容が消去される。

昔は検索内容を変更するたびにテキストを選択して Del を押していたのを思い出す。

色指定は type="color" だ。

すべてのプラットフォームにおいて、このコントロールは 6 桁の 16 進数による RGB 値を返す。

JavaScript でプロパティー .value を見ると例えば '#0cdeed' のような文字列が得られる。

《フォームに入力された内容の自動検証機能》について。

フォーム検証機能を有効にするために特別なマークアップは必要ない。なぜなら、デフォルトで有効だからだ。逆に検証を無効にしたい場合は、novalidate 属性を使う。

<form novalidate>
  <input type="email" id="addr">
  <input type="submit" value="Subscribe">
</form>

入力欄単位では入力必須属性というものがある。属性 required を <input> に付加する。ブラウザーによっては

入力必須フィールドの見た目を変更することがある。

さらに、

入力必須フィールドに何も入力しないままフォームを送信しようとすると、そのフィールドが入力必須であり空にできないというポップアップを表示する

ようなこともする。

10 章 マイクロデータによるマークアップの拡張

独自の要素を作り上げることが無理なら、Web に意味を持たせたい Web 制作者はどうすればよいだろうか。

選択肢は次の三つあるが、第三の項目が本章の主題だ：

マイクロデータとはデータの一種ではなく、

独自の語彙から構成される名前と値のペアによって、あるスコープ（範囲）内の DOM を意味付けする仕組みだ。

例えば HTML5 要素すべての集合を考えると、これは語彙の一つと言える。《マイクロデータは独自の語彙を中心として機能する》と述べている。

名前と値のペア、スコープに関しては後述の節で実例に即して説明される。

マイクロデータは、Web ページにすでに表示されているデータ に意味を追加するものだ。

§10.3-10.4 は次の資料を見ながら読み進めるといい：

特に、HTML ファイル同士の diff を確認すると実際になされた作業が明瞭になる。

まず必要となるのは名前空間で、これは単純な URL だ。

本書の例では上の廃止済み URL を参照する。今のところは一意な識別子でさえあればいい。この語彙を次の集合で定義したと考える：

  • name

  • photo

  • url

この条件でマイクロデータを対応前 HTML に対して追加するとする。

最初にしなければならないのは、itemtype 属性を追加し、使用するマイクロデータ語彙を宣言することだ。次にしなければならないのは、itemscope 属性を使って、語彙のスコープを宣言することだ。

というわけで、いちばん外側の要素である <section> に次の属性を追加する：

  • itemtype="http://data-vocabulary.org/Person"

  • itemscope

ここからキーと値のペアを HTML 上で行う。表 10-1 のように、要素ごとに値の在り処が異なる。

<h1 itemprop="name">Mark Pilgrim</h1>

日本語で言うと、「これは http://data-vocabulary.org/Person 語彙の中の name プロパティで、その値は Mark Pilgrim だ」という意味になる。

この調子で photo と url も意味付けしていく（表 10-1 に注意する）。

実は、http://data-vocabulary.org/Person へ行けば、プロパティの一覧を見ることができる。マイクロデータの仕様はそこまで要求していないが、確かにこれは「ベストプラクティス」だと言えるだろう。

現在では当該 URL は廃止されている。著者の主張を理解するには先述の移行先候補 URL を見ればいい。

場合によっては DOM 構造にも手を入れていく。実際に書かれている内容が二つのプロパティーにまたがっているような場合だ。またがっているということは、

それぞれの箇所をダミーの <span> 要素で囲えば、それぞれの <span> に別個のプロパティを宣言できる。

<dt>Position</dt>
<dd><span itemprop="title">Developer advocate</span> for
    <span itemprop="affiliation">Google, Inc.</span></dd>

Person 語彙の address は、これ自身が独自の語彙を持っている。したがって Mailing Address の項目部分を

<dd itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address">

のように書き換えることになる。マイクロデータ関連の属性三つがあることになる。

日本の住所表記と各プロパティーの対照表 (p. 199) がありがたい。

マイクロデータは検索エンジンが参考にする可能性がある。検索結果ページに構造化された情報を統合して表示することがある。

Google は、リッチスニペットの一環としてマイクロデータをサポートしている。

<https://search.google.com/test/rich-results> と思われる。本書のコードを試すことは可能だ。しかし、語彙が廃止されているためだと思われるが、芳しい結果にはならない。検証ツールは Schema.org Validator がわかりやすい。

誰かが「Mark Pilgrim」を検索し、 かつ Google がこの「about me」ページを検索結果に含めようと判断し、 かつ Google がそのページにもともとあったマイクロデータが表示する価値のあるものだと判断した場合には、検索結果の表示は図 10-1 のようなもの（引用註：マイクロデータで拡張された人物の検索結果の見本画像）になるだろう。

検索結果ページで特殊な表示を目にすることがあるが、これだったのか。

検索エンジンの会社と特別契約を結べるような大企業でなくても、検索エンジンの結果表示をカスタマイズできるのだ。

HTML5 では不可視データを注釈としてマイクロデータに加える方法が提供されている。このテクニックは、あくまでも最後の手段として使用してほしい。（略）機械のみが可読な不可視データは、すぐに陳腐化してしまう。

<meta> 要素は特別に取り扱われる。プロパティの値は、その content 属性となるのだ。

付録 A （ほぼ）アルファベット順の HTML5 機能機能方法

<command> 要素は存在しない。

<datelist> 要素は <option> 要素を含み、他の入力欄の中で選択可能である選択肢や推奨選択肢を表す。次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist>

<details> 要素は折りたたみブロックを構成するのに用いるものだ。次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details>

<device> 要素は存在しない。

<iframe sandbox> および <iframe srcdoc> については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe>

先述したように <input type="datetime"> は存在しない。

<meter> 要素については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter>

<output> 要素については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/output>

<progress> 要素については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress>

<track> 要素は <audio> や <video> 要素の子にするものだ。次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/track>

<video> 要素の poster 属性はビデオのダウンロード中に表示する画像の URL を値に取る。YouTube で言うとサムネイルに相当する。

contentEditable 大域的属性については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable>

History はブラウザーの戻る・進むの履歴のための API だ。次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/History>

document.getItems は undefined だからマイクロデータは使えないということか。

EventSource については次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/EventSource>

セッションストレージについては次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage>

UndoManager は存在しない。

WebSocket については次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/WebSocket>

See also

Network requests で少し見ていた。

Web SQL データベース。window.openDatabase は存在するが、インターネット上にまともな情報がない。

Web Workers について次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/Worker>

W3C Widgets は存在しない。

XMLHttpRequest については次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest>

window.applicationCache が存在しない。

クロスドキュメントメッセージングについては次を参照： <https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage>

ドラッグアンドドロップは取り扱いが難しいと記憶している。 draggable 大域的属性については次を参照： <https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/draggable>