2018年に於ける HTML の役割（実践編）

2018年に於けるHTML の役
割（実践編）
『新卒OJT』 or 『HTML をボチボチ触ったことがあ
る人に向けて』

Name: UX Ojisan
Career: 業界20年目
Job: 今はUX Designer
MF レンズを300 本以上持っていて、
マウントの無いレンズを3D プリンタで自作し撮影し
ている。

1. 基本知識
HTML バージョン
ブラウザシェア、サポートブラウザとその選定
PC 版 / SP 版 / Responsive Web Design
F12 ツール
ソースを表示と F12 ツールでソースを見る際の違い
F12 ツール概要
インタプリタ
CSS、JS との棲み分け
標準化の必要性
CSR / アクセシビリティ

2. SEO
クローラビリティ
SEO
Google: 検索エンジン最適化（SEO）スターターガイド
Google Search Console
SEO 対策の推移：構成要素 → 被リンク → ユーザ行動
Google Analytics
クローラによる JS の解釈
robots.txt、sitemap.xml
MFI
Rich Snippets
Rich Result（+ Rich Cards）
AMP
PWA
パフォーマンス計測

3. タグの基本とセオリー
タグに関するセオリー
よく使い、とにかく頻繁に出てくるタグ
よく使うが、１ページあたりに使う箇所は限られるタグ
たまに使うタグ
document outline
暗黙的・明示的アウトライン
inline、inline-block、block 各要素
formタグの意味と挙動、特殊なnameとvalue属性
table タグ

4. ほか
Cookie、Web Storage
キャッシュ
data 属性
WAI-ARIA
SVG

1. 基本知識
HTML バージョン1/2
1991年にティム・バーナーズ・リーが世界で初めての Web サイトを公開。また、WWW
Client と呼ばれる所謂「ブラウザ」も同時に公開したが、それを Open Source として公
開した点が Web の発展に大きく寄与したと考えられる。
1994年にかけて、Mozaic、Netscape Communicator、Internet Explorer といったブラ
ウザが公開されたが、独自仕様の乱立により、Web サイト制作者側は大きな混乱状態に。
そこで、1994年に Web のルールを制定する W3C が発足。
W3C では以下のように HTML の仕様を策定し、バージョニングする形で勧告。
HTML 3.2 = 1997-01-14 / HTML 4.01 = 1999-12-24
XHML 1.0 = 2000-01-26 / HTML5 = 2014-10-28
XHTML1.0 準拠のdoctype宣言は以下の通り。
宣言によりレンダリングモードが適宜変わる。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja" dir="ltr" lang="ja">

1. 基本知識
HTML バージョン2/2
そんな最中、 W3C の方針に異論を持った有志により 2002年頃に WHATWG が発足。
WHATWG はバージョニングは行わず、Living Standard と呼ばれる絶えずアップデートを
続ける形で仕様を策定。
W3C は定期的に HTML のバージョンアップを続けているが、自信で仕様を策定する体力
はなく、WHATWG からフォークを繰り返しバージョニング作業を進めるというのが実情
のようだ。明確なバージョンとして定義してもらえるのはわかり易くはあるが…
現在では、Google、Mozilla、Apple は WHATWG、Microsoft は W3C に準拠をしている
様子。
また、HTML5 準拠の HTML 宣言は以下のようになる。
<!DOCTYPE html>
<html lang="ja" dir="ltr">
HTML Living Standard
HTML5.2

1. 基本知識
ブラウザシェア、サポートブラウザとその選定
昨今のブラウザのアップデートは
Windows IE = Windows Update
Mac Safari = ソフトウェア・アップデート
モダンブラウザ（Chrome、Firefox） = 自動アップデート
iOS = ソフトウェア・アップデート
Android = …
というように実施されるが、数年前まではブラウザアップデートは大ごとで、ユーザによ
る手動アップデートはほぼされない状態。結果、10 年近く前に作られたブラウザを Web
サイトはサポートしなくてはならないなど、業務リソースの多くがレガシーブラウザ対応
に割かれるような状況が続いた。
企業・Web サイトがサポートするブラウザの判断基準としては概ね二つで、以下の通り。
実際にはデバイス毎のアクセス状況も加味されたりする。
OS がバンドルするブラウザが、メーカーのサポート期間中かどうか
ブラウザの、最新メジャーバージョンと一つ前のメジャーバージョン

1. 基本知識
PC 版/ SP 版/ Responsive Web Design 1/2
以前、フィーチャーフォンと呼ばれる、PC と比較すると低端末スペック、低回線速度、
低解像度の所謂「ガラケー」でも Web サイトが閲覧できるよう、各大手携帯キャリアが
独自の HTML 仕様を提唱し、実装されたことがあった。
これらはよくガラケーサイトないしガラケー版と呼ばれる。
後期のガラケーでは、フルブラウザを搭載したものもあったが、小さい画面と上下左右矢
印で PC 版を操作する仕様は最低の UX だった。
2007 年に登場した iPhone を皮切りに、スマートフォンと呼ばれる高端末スペック、高回
線速度、高解像度の所謂「スマホ」が登場した。独自仕様が多かったガラケー版と違い、
小さいモニタでも操作性が担保される所謂「スマートフォン版 Web サイト（以降 SP
版）」が確立され、それらはこれまでの PC 版と同じ仕様のもと、Viewport の指定のみで
制作できるということもあり、広く浸透することになる。

1. 基本知識
PC 版/ SP 版/ Responsive Web Design 2/2
Web サイト制作者は、これまでの PC 版に加え SP 版も追加で制作し、閲覧端末をサーバ
サイドないし JavaScript で振り分け、それぞれ PC / SP 版専用の HTML を返却するのが
セオリーだった。しばらくして、レチナディスプレイの登場、端末スペックの向上などの
要因をもとに、単一の HTML を CSS3 Media Queries を用いて PC / SP それぞれに最適な
表示を提供しようという『Responsive Web Design（以降 RWD）』が提唱された。
一見メリットしかないように思えるが、実装に際してはメリットのみでなく、デメリット
も伴う。
◎ HTML テンプレートは一つで済む
◎ ランニングコストは低く済む
◎ SEO 面で Google が推奨している
◎ タブレットも最適化できる
✕ Initial の開発コストは高い
✕ 構成要素の出現順序は基本的に変更不可、SP / PC で最適な UI を突き詰めにくい
✕ CSS / JS / HTML いずれの記述量も増える

<!DOCTYPE HTML>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="
width=device-width,initial-scale=1.0,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no">
<meta name="format-detection" content="telephone=no">
</head>
<body>
<h1>SP</h1>
</body>
</html>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
</head>
<body>
<h1>PC</h1>
</body>
</html>
<!DOCTYPE html>
<html lang="ja">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width,initial-scale=1">
</head>
<body>
<h1>Responsive</h1>
</body>
</html>

1. 基本知識
F12 ツール
ソースを表示とF12 ツールでソースを見る際の違い
ソースを表示
サーバから返却された状態の HTML
F12 ツール
サーバから返却された HTML 上の JS が書き換えた状態の HTML
F12 ツール概要
全て使いこなすのは難しい ...

1. 基本知識
インタプリタ
HTML はインタプリタ言語であり、それに加えてインターネット回線を経由してコードを
ダウンロードするという前提もついて回る。処理・解釈は DL が済んだものから、一行ず
つ実施される。また得意な側面として、
外部ファイルとして読み込む css は並列に読み込み実行
外部ファイルとして読み込む JS は、直列に読み込み・実行
但し async 属性付きの JS は並列に読み込み・実行
結果何がどうなるかと言うと、
（case by case だが）JS ファイルを head 内に置くのは読み込み遅延の原因
CSS ファイルから CSS を読み込むような記述はレンダリング遅延の原因
JS 読み込み時の async 属性は有用だが、ライブラリ系の読み込みには使えない
現時点のブラウザの同一ドメインからのファイル同時読み込み数は最大で 6。
multiple domain 化、http(s)/2 の導入、回線速度の高速化により、ファイルの読み込みに
対してデリケートにならなくても良い状態になりつつあるが、最終的には細かい事象の積
み重ねが Web サイトの表示速度を決めることになるので、インタプリタの特性を見極め
つつ外部コンポーネントを活用する必要がある。

1. 基本知識
CSS、JS との棲み分け
HTML は情報、骨組み
CSS は装飾（場合により振る舞いも *1）
JS は振る舞い（場合により骨組み *2、装飾も *3）
（*1）
CSS3 を利用し、アニメーションを実装するケースも
（*2）
React、Vuejs、AnglarJS 等のフレームワークの利用により、結果的に処理するのは HTML にはなるが、
HTML そのものは書かないケースがある。
（*3）
特に JS プラグインによるアニメーションや、HTML × CSS では表現しきれない複雑な表現は、JS で HTML /
CSS を書き換えて表現することもある。
*2、*3 は、事前に HTML ないし CSS で書いておくか、あとから JS で操作・表現するかの
違いで、HTML = 骨組み、CSS = 装飾、の役割は変わらない。

1. 基本知識
標準化の必要性
公開期間の短い単発ページはいざしらず、特に数年間継続して公開し続けるような息が長
いページに関しては、WHATWG や W3C の提唱するルールに則って HTML を書いておく
ことは重要。
各仕様は後方互換を考慮して考案されており、標準化仕様に則って実装することで、基本
的にはブラウザ・デバイス間の互換性も担保できることになる。
CSR / アクセシビリティ
企業活動の大きな理由は営利ではあるが、企業活動の躍進に伴い、企業活動が与える社会
への影響や、ステークホルダーの要求を受け入れる必要が出てくる。
質の低いコード（サービス）の公開等により、企業価値を軽んじられるようなことのない
よう、心がけておく必要がある。

2. SEO
クローラビリティ
検索エンジンの存在を無視して成り立つ Web サービスは稀だろう。
名指しで Web サービスを利用する際も Google や Yahoo と言った検索エンジンでサービ
ス名称を入力して遷移することも多く、PC / スマートフォン、いずれの UI も、まずフリ
ーワードを入力し結果的に検索エンジンへ遷移する流れが当たり前になっている。
ユーザが入力したフリーワードに対して表示される結果のアルゴリズムは非公開で、ラン
ク付けの為の指標は 200 を超えるとも言われているが、各サービス担当者は、上位に表示
される為に SEO を意識したサイト作りは避けられないだろう。
検索エンジン側としては、Web サイトの評価のために Web サイトの内容を知る必要があ
るわけだが、それにはクローラと呼ばれる専用の UA を持ったプログラムを用いて Web
サイトを巡回しページ内容を取得していく。専用の画面から巡回を促すことも可能だが、
基本的には検索エンジン側の任意のタイミングでサイトを巡回していく。
サイト運営側としては、クローラの特性を把握した上で、クローラビリティを担保した形
で Web サイトを作成する必要がある。日本の検索エンジン２大巨頭は Yahoo! Japan と
Google だが、Yahoo! Japan の検索エンジンは Google 製である。

2. SEO
SEO 1/7
SEO = Search Engine Optimization。
検索エンジン上での最適な表示、検索結果で上位表示させる為の取り組み全般の事。
SEO と聞くと、なんとなくストイックで定量的なアプローチと感じるかもしれず、実際に
実施する施策は定量数値の改善だったりするかもしれないが、結局『ユーザにとって価値
あるコンテンツを提供できているかどうか』が最良の SEO だと考える。
検索結果のランク付けの為の数百のアルゴリズムも AI の活用も、全てはユーザにとって
価値ある体験を提供できているかどうかの判断の為ではないか。さもなくば Google がこ
こまでユーザに受け入れられはしないだろう。

2. SEO
SEO 2/7
Google: 検索エンジン最適化（SEO）スターターガイド
https://support.google.com/webmasters/answer/7451184?hl=ja
Best なコンテンツ作りの為に、Google 視点でどうすべきかが概ねここに書いてある。

2. SEO
SEO 3/7
Google Search Console
Google 検索結果上でのサイトパフォーマンスを監視するツール。
https://www.google.com/webmasters/tools/home?hl=ja
ページが持つ課題や、実装面のエラーの通達
新たに作成した Web サイトのクローリング促進
Web サイトがクローラからどのように見えているか確認
などを評価し、通達してくれるツール。

2. SEO
SEO 4/7
SEO 対策の推移：構成要素→ 被リンク→ ユーザ行動
技術の発達、特に AI やビッグデータの活用によりクローラや Web サイトの評価アルゴリ
ズムが日々改善され、それに伴い SEO の評価観点が変化し続けている。
Internet 黎明期は、検索ワードがページ内に多いほど検索結果上位に表示するような状況
で、不可視のテキストを html に大量に書き込むような Web サイトが台頭。
しばらくして、他ページからのリンク数が評価観点に組み込まれ、これまた意味のない
SEO 用の専用のサイトからサイトにリンクを貼る行為が業者ぐるみで横行。
最近では、Twitter、Facebook と言った Social サービスでの言及やそこからの被リンク、
キュレーションメディアの価値向上、長文記事最強説など、様々な要因がランキング形成
に引き続き寄与している。
それら様々な要因を前提としつつも、昨今重視されているのが『ユーザ行動』。
スマホ用 OS Android を自社開発、巨大アプリプラットフォーム Play Store を保持、
Google を誰もが使うようになり、サイト改善の為の計測ツールでさえ Google 製、ありと
あらゆる側面からユーザの行動を把握できる Google が、ユーザが満足のいく体験ができ
たかどうかを判断できていると想像するのは容易い。

2. SEO
SEO 5/7
Google Analytics
Web サイトで規定の JavaScript を読み込むことで、Web サイトに訪れたユーザの行動を
細かく収集し、専用の管理画面から様々な定量データを取得できるツール。

2. SEO
SEO 6/7
クローラによるJS の解釈
数百あると言われている検索結果のランク付けの要因の中でも、頻繁に取り沙汰されるの
が JavaScript で生成した HTML の解釈。
数年前に bot と言われて発想するのは、巡回するプログラムが html を取得しそこに書か
れている情報を評価するというようなものだった。
ところが、現代ではユーザの操作や非同期通信を含めたデータの取得によって JavaScript
が生成する html の評価は、一般のエンジニアであっても実現可能な状況になっている。
AJAX 黎明期には AJAX crawling scheme と称して、独自の Scheme を介することでクロ
ーラビリティを担保するような仕組みが検討されていたが（2015年に中止）、上の通り技
術の発達に伴い、曖昧だった JS で生成する HTML の解釈に関しても、『Google bot は
JS で生成する HTML を評価できている』と明言するに至った。当然ランキングにも影響
があると見做して良いだろう。
また、Search Console › fetch as gogle では、具体的なページのレンダリング状況が確認
できる。

2. SEO
SEO 7/7
robots.txt
robots.txt は、専用のフォーマットに従って記述することで、クローラの行動を制御でき
るファイル、各ページの meta タグで、ページ個別の制御も可能。以下は、対象ページを
Google にインデックスさせず、ページ内のリンクを一切回遊させたくない際の記述（よく
被リンクを渡さないなどという言い方をするが、自社サービスにとって SEO 面でメリット
はなくても微塵でもデメリットが考えられるケースで、敢えて関わりをもたない為に利用
する）。
<meta name=”robots” content=”noindex,nofollow”>
sitemap.xml
sitemap.xml は、Web サービスの index を通達・促す為にファイルのパスと補足情報を規
定のフォーマットに従って記載したもの。Search Console から sitemap.xml の存在を報
告することで、基本的には sitemap.xml に記載した URL をインデックスさせることができ
る。

2. SEO
MFI 1/2
Mobile First Index の略。
主だった検索エンジンのランク付け要因に活用するのは、基本的には PC 版 Web サイト。
つまり SEO は PC 版で実施するものだった。これは以前は PC 版しか存在していなかった
為、検索エンジンもランク付けに利用するのは PC サイトという前提を持ち続け、またア
ルゴリズムも煩雑になるだろうといった点が考えられる。
一方で、現在では PC サイトよりも SP サイトの閲覧が増え、ランク付けに関しても PC 版
のみを参照するのは無理があると考えだした。検索エンジンが仕様変更を実施する際は、
事前にその内容とマイルストーンを公開した上で実施することが多いが、クローラが巡
回・解析するサイトを PC 版から SP 版変更する変更を MFI と呼び、着々と仕様変更を進
めている。

2. SEO
MFI 2/2
因みに、以下のような要因を解決するために URL の正規化が必要だが、
PC 版と SP 版を別 HTML として配信している
サブドメイン、末尾の / の有無
類似するページの一元化
以下のようなタグを入れることで対応できる。

<link rel="alternate"
media="only screen and (max-width: 640px)" href="［SP・FP URI］">

<link rel="canonical" href="［PC URI］">
PC 版が起点となる為、SP URL を alternate（代替 URL）で指定。PC 版は起点であるか
ら SP 版から見ると canonical（規準の URL）としての PC URL を指定。… というように
現在は PC 中心の指定方法だが、MFI 対応では意味合いが逆となる。ところが、混乱を避
ける為にこれらの記述の変更の必要はナシというアナウンスもされている。

2. SEO
Rich Snippets 1/2
Rich Snippets = microdata 及び JSON-LD を利用し、HTML に正確なページ情報を指定し
たもの。記述できる情報カテゴリは、主に Schema.org で定義される。
Rich Result、Rich Cards = 言い回しは頻繁に変わる。クローラが HTML に埋め込まれた
リッチスニペットを参照し、検索結果の専用エリアで表示される情報の事。
左：Rich Result、右：Rich Cards
テストツール
Rich Result Test
非実用レベル
Rich Snippets Testing Tools
実用レベルだがバグも多い

2. SEO
Rich Snippets 2/2
前ページの例では『Google 検索結果上の Rich Cards・Rich Result の為の Rich Snippets
の活用』というような意味合いになってしまったが、Rich Result 等への掲出期待等を問
わず、ページの内容は Schema.org で定義されている各スキーマに則りページの内容を定
義しておく事は重要。
HTML 自体も仕様の充実が進み多くの項目を定義できるようになったものの、表現が多様
化した Web ページの内容を HTML タグのみでクローラに伝えるのは難儀な事も多く、
json-ld や microdata による明確なページ情報の定義により、はじめてクローラブルにな
るというケースも少なくないだろう。
実装漏れの可能性を排除すれば、microdata よりも json-ld のほうが管理し易い
Structured data testing tool の Bredcrumblist › item の image 必須エラーはバグ
将来的に何がどう検索エンジンに採用されるかわからないので、実装できるものはし
ておく

2. SEO
AMP 1/2
AMP = Accelerated Mobile Pages
Mobile ニュースサイトの表示速度の遅さに業を煮やした有志たちが、Mobile サイトのパ
フォーマンスを改善させる為に考案した、「独自 JS ライブラリ群をベースとする、高速
に Web サイトを表示させるためのルール」という立ち位置だったが、現在は、
1. Google の表示速度 Up の為の養分 = いわゆる AMP 版
2. Google にメディアの検索結果を表示 = いわゆる、AMP版を利用したRich Cards
3. News や動画、ほか定義済み検索ワードに応じたリッチ情報を表示 = Rich Result
という立ち位置になっている。
1 は、Google 検索結果の［AMP］マークが付いているリンクを押した際に出てくるペー
ジの事で、現在の対応状況は以下の通り。
https://developers.google.com/search/docs/guides/about-amp
いずれも、クリックで表示されるページの URL は、google.co.jp。
仕組みとしては、ぐるなびの amp ページを fetch ＆ chache し、キャッシュした情報をユ
ーザに表示することで高速化を実現している。

2. SEO
AMP 2/2
AMP 版は、HTML をベースに独自のルールを設けたいわば HTML の拡張版。
CSS は inline で 50KB 以内、JavaScript は自由に書けないが、様々な機能を実装する為の
AMP-JS が利用可能、img タグは amp-img タグを利用、など、いくつかの実装ルールが存
在し、Google 検索結果に反映させるためには、基本的には Valid 状態にしておく必要があ
る。
URL に#development=1 を付与することで、ブラウザの console でデバッグが行える。
https://www.ampproject.org/

2018年に於ける HTML の役割（実践編）

2. SEO
PWA
Progressive Web Apps の略。
個人の見解となるかもしれないが、『いわゆる App（アプリ）でできて Web でできない
ことを達成しよう』が PWA が達成しようとしていることと考える。
大きなところだと、Push 通知、スタンドアローン起動（スプラッシュ画像表示）、オフ
ライン利用、ホームスクリーン追加（インストール）で、Android は既に実用レベル、
iOS でも 11.3 から少しずつ対応が進んでいる。
オープンソースだが主に開発を推進しているのは Google で、前述の通り Android が iOS
App Store の牙城を崩したいのでは… と勘ぐっていたので iOS が PWA 対応を進めるとは
考えていなかった… と考えるのは無粋だろうか。
スタンドアローン起動、オフライン利用、ホームスクリーン追加はクライアントサイドの
実装のみで対応が可能だが、App Shell に基づいて発想された Pre Cache と Runtime
Cache は、それぞれ、ファイル更新後も仕組み上一度は古いものが表示される、基本的に
二度目のロード時以降に恩恵がある、というデメリットや改善の余地が現段階ではあり、
新たなキャッシュ手法が提唱されるのではないかという気もしている。
App Shell Model / Workbox / manifest.json Generator

2. SEO
パフォーマンス計測
page speed insights
test my site
lighthouse

タグに関するセオリー 1/3
ほぼ必須で、表示要素に直結しない（body タグは除く）タグ
html, head, title, meta, link, body, script
よく使い、とにかく頻繁に出てくるタグ
div, span, p, dl, dt, dd, ul, ol, li, a, h1, h2, h3, h4, h5, img
よく使うが、１ページあたりに使う箇所は限られるタグ
section, article, header, nav, footer
たまに使うタグ
time, blockquote, ...

W3C HTML5 による Content Model
Metadata content
base, command, link, meta, noscript, script, style, title
ow content
a, abbr, address, area (if it is a descendant of a map element) article, aside, audio, b,
bdi, bdo, blockquote, br, button, canvas, cite, code, command, datalist, del, details, dfn,
div, dl, em, embed, eldset, gure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup,
hr, i, iframe, img, input, ins, kbd, keygen, label, map, mark, math, menu, meter, nav,
noscript, object, ol, output, p, pre, progress, q, ruby, s, samp, script, section, select,
small, span, strong, style (if the scoped attribute is present) sub, sup, svg, table,
textarea, time, u, ul, var, video, wbr, text

Sectioning content
article, aside, nav, section
Heading content
h1, h2, h3, h4, h5, h6
Phrasing content
a (if it contains only phrasing content) abbr, area (if it is a descendant of a map
element) audio, b, bdi, bdo, br, button, canvas, cite code, command, datalist, del (if it
contains only phrasing content) dfn, em, embed, i, iframe, img, input, ins (if it contains
only phrasing content) kbd, keygen, label, map (if it contains only phrasing content)
mark, math, meter, noscript, object, output, progress, q, ruby, s, samp, script, select,
small, span, strong, sub, sup, svg, textarea, time, u, var, video, wbr, text

document outline
document outline = セクショニング・コンテンツと見出しタグによる、HTML 文書構造の
階層を定義するための考え方。HTML5 勧告時にセクショニング・コンテンツが登場し、
より明確に定義できるようになった。
アウトラインは、
body タグ or セクショニング・コンテンツ + ヘディング・コンテンツ
で形成され、ブラウザ・クローラに適宜解釈される。
document outline に頓着を持つエンジニアが少なく、結果正しい document outline はマ
イノリティであり、Google 側も軽視せざるを得ないのが実情なのではないだろうか。本
来であれば document outline を意識したマークアップはとても重要。
アウトラインの確認は、HTML5 Outliner を利用すると便利だが、考慮されていない点も
多く、自信の目と頭でアウトラインを確認できるようになる必要がある。
HTML5 Outliner

暗黙的・明示的アウトライン1/4
<body>
<h1>ジョジョの奇妙な冒険第一部に関する文献</h1>
<h2>登場人物</h2>

<h2>ストーリー</h2>


</body>
<body>
<section>
<h2>登場人物</h2>

</section>
<section>
</section>
</body>
上のコードで形成されるアウトラインは以下のようになる。
1. ジョジョの奇妙な冒険第一部に関する文献
1.1 登場人物
1.2 ストーリー

ページ内の構成要素は hx タグで定義をする。hx タグが影響する範囲は次の hx タグが出
現するまでで、これを暗黙的アウトラインと呼ぶ。出現した hx タグが、一つ前の hx タグ
よりも小さい際には階層が一つ下がり、親の hx タグの意味を継承する。
上のコードの <h2>登場人物</h2> 部分は問題ないが、 <h2>ストーリー</h2> 部分は、リ
スティング広告にまで影響してしまっており、これは意図通りではない。
一方下のコードは、上のコードに加えて section タグを利用している。section タグは、
セクショニング・コンテンツと呼ばれる明示的に階層レベルを定義するタグで、更に見出
しの影響範囲を限定できる。セクショニング・コンテンツを利用して形成されたアウトラ
インは、明示的アウトラインと呼ぶ。
<section>
</section>
上のコードでは、section タグでストーリー見出しが影響する範囲を限定し、リスティン
グ広告エリアがストーリーにかからないようにしている。

<body>
<section>
</section>
</body>
<body>
<nav>

<nav>
</body>
<body>
<h1><img src="title.png" alt="ジョジョの奇妙な冒険第一部に関する文献の見出し"></h1>
</body>
一番上は所謂 h1 に該当するものがないまま階層が一つさがっており、h1 に該当するもの
がないため NG。
２番目は、見出しより先にナビゲーションが出現する際にやりがちだが、nav タグはセク
ショニング・コンテンツで、h1 より先に一階層下がってしまっている為 NG。
３つ目は h1 で画像を指定したケースだが、避けたほうが良い。

<body>
<section>
</section>
</body>
<body>
<section>
</section>
</body>
<body>
<section>
</section>
</body>
上の３つはいずれもアウトラインとして正しいが、２番目は HTML5 勧告時に避けたほう
が良いと言及もされた為、避けたほうが良いだろう。
１番目もアウトラインとしては正しいが、数字は 1 から順番に付与するのが望ましい。

inline、inline-block、block 各要素

1/3
ユーザによるデータ入力を受け付け、JavaScript 等を利用することなく入力データをサー
バへ送信できるのが form タグを始めとしたフォーム要素である。
代表的なタグとして、以下のようなものがある。
form, input, select, textarea, button, label

2/3
以下は、ユーザに「叫び」を入力してもらい、送信ボタン押下で /hoge.php にデータを送
信するフォーム要素の例。
<form type="get" method="/hoge.php">
叫び：<input type="text" name="shout"><input type="submit">
</form>
叫び：送信
上のフォームで「ウリィィィ」と入力し送信をすると、hoge.php というプログラムが存
在していない為 404 になるが、URL としては以下のようになる。
/hoge.php?shout=ウリィィィ
これは、
1. type="submit" という属性値を持つ input 要素を押下時に、
2. 入力要素の name 属性値と value 値を、URL の ? の後に name=value として、
3. form タグの method 属性値にデータを送信する

3/3
以下は前のページの要素を、タグや属性値を加え改修をしたもの。
<form type="get" method="/hoge.php">
<label>叫び：<input type="text" name="shout" value="ウリィィィィィィィィ"></label>
叫んだキャラクター：<label><input type="radio" name="character" value="dio">ディオ</label> /
<label><input type="radio" name="character" value="jonathan" checked>ジョナサン</label><br>
吸血鬼かどうか：<label><input type="checkbox" name="vampire" value="1"></label><br>
<input type="submit" value="準備はいいか俺はできてる">
</form>
叫び：ウリィ
叫んだキャラクター：ディオジョナサン
吸血鬼かどうか：
準備はいいか俺はできてる
送信時の URL は以下の通り。
/hoge.php?shout=ウリィィィ&character=※※※&stonemask=1
label タグで囲う事で、タップの範囲を label 選択エリアに伸張できる
input type="text" に value 値を付与することで、値をデフォルトで入れておける
input type="radio" or "checkbox で、ラジオボタン・チェックボックスが利用可

table タグ
<table>
<tr>
<th>ブランドー家</th>
<th>ジョースター家</th>
</tr>
<tr>
<td>ディオ・ブランドー</td>
<td>ジョナサン・ジョースター</td>
<td>ダニー</td>
</tr>
<tr>
<td>後に吸血鬼</td>
<td>波紋使い</td>
</tr>
</table>
ブランドー家ジョースター家
ディオ・ブランドージョナサン・ジョースター
後に吸血鬼波紋使い

table タグ
<table>
<caption>ジョジョ第一部キャラクター一覧</caption>
<colgroup>
<col style="width: 320px;" /><col style="width: 320px;" /><col style="width: 200px;" />
</colgroup>
<thead><tr>
<th>ブランドー家</th>
<th colspan="2">ジョースター家</th>
</tr></thead>
<tbody><tr>
<td>ディオ・ブランドー</td>
<td>ジョナサン・ジョースター</td>
<td>ダニー</td>
</tr></tbody>
<tfoot><tr>
<td>後に吸血鬼</td>
<td>波紋使い</td>
<td>犬</td>
</tr></tfoot>
</table>
ジョジョ第一部キャラクター一覧
ブランドー家ジョースター家
ディオ・ブランドージョナサン・ジョースターダニー
後に吸血鬼波紋使い犬

4. ほか
Cookie、Web Storage 1/3
いずれもベンダー側の Script によってブラウザに値を保持しておくことができる機能。で
きることやその構造は大きく異なる。
いずれも読み書き方法は異なるが、key=value 形式で値を保持する。

4. ほか
Cookie は Web 黎明期から存在しており、存在するプロパティは document.cookie ただ
一つ。引数・戻り値のいずれも型は String で、既定のデリミタで区切られた文字列の中
に、max-age、expires、domain、path、secureといったいわばオプションが存在する。
オプションによる特性としては、以下のようなものがある。
セッション中のみ値を保持、もしくは指定の期限中値を保持し、期限を超えると自動
削除される
既定の host 名のみでやり取りを可能にする（.hoge.com とすること
で、www.hoge.com でも piyo.hoge.com でも読み書きが可能となる）
上の host 名に加え、指定ディレクトリ配下のみ読み書きを有効にできる
ブラウザからの http リクエスト時、html、gif、css、などファイル種別を問わず、各
ファイルが設置してある host 名に対して有効な cookie の値は、全て HTTP Header
に送信される（html とその他リソースを別ドメインに設置することで cookie 送信を
なくしリクエスト総量を減らす Cookie Free Domain を取得し運用する手法がある）
サーバサイドでも Cookie の取得、書き込みができる
host 毎に書き込める Cookie 数に上限がある
値の容量に上限がある

4. ほか
Web Storage は、Local Storage と Session Storage を包括しており、いずれも
key=value 形式で値を読み書きでき、読み書き用の専用プロパティ・メソッドが存在す
る。Web Storage は HTML5 が勧告されたあたりに提唱されたもので、現在では広く実装
され利用に際する障壁はほぼ無いと言える。
Session Storage はセッション中のみ値を保持するもので、Local Storage は値を永久に保
存しておくもの。プロパティやメソッドもほぼ共通。
書き込み可能な容量が大きいことと、値に型が利用可能なこと、ビルトインのプロパテ
ィ・メソッドの充実等があるが、できることとしては Cookie の下位互換と感じる。特に
Local Storage の期限指定ができなく、一度書き込まれた Local Storage が再訪時にベンダ
ー自身の手により削除されない限りは永久に残り続ける点などは、スマホなどの限られた
ストレージ下での Web 閲覧機械が多い現代では、仕様上の大きな難点と言える。
昨今の Cookie 読み書きは、記述を簡易にする為にプラグイン等を利用する事が多いが、
Local Storage 利用時も、値に期限を持たせ、不要になった Local Storage は再訪時に書き
込んだベンダー自らが削除するような運用が必須だろう。

4. ほか
キャッシュ
キャッシュと一口に言ってもその実さまざまだが、HTML を書く人に関連しそうなものと
しては以下のようなものがある。
Web サイト再訪時の読み込み最適化の為のブラウザによるファイルキャッシュ
= ファイル DL 時の HTTP Header の記載に従い、ブラウザがキャッシュする
ページ要素のダイナミックな切り替え・表示の為のファイルの事前キャッシュ
= シームレスな画像表現の為、JS 等で事前にファイルのリクエストを出しておく
Service Worker によるローカルキャッシュ
= 先に書いたとおり
CDN によるキャッシュ等を活用したファイル配信の最適化
= サーバからのレスポンスを、各地に設置した拠点へキャッシュし配信することで、配信のラグの最適化
と本サーバへのリクエストを減らす仕組み。一度キャッシュしたファイルは、期限が切れるのを待つか、
更新時に手動でキャッシュクリアをする必要がある。ホスティング費用と CDN の費用の比較と、配信ス
ピード等を考慮し導入が検討されることになるだろう。

4. ほか
data 属性1/2
HTML タグへ付与する属性だが、data- から始めることで、自由な属性名を付与でき、専
用の dataset プロパティで読み書きできるもの。
また CSS からもアクセスできる為、疑似要素等と組み合わせることで :hover 時の要素表
示や ::after による要素表示にも使える。但し、data 属性値に対するクローラビリティは
低い為、SEO 面で活きるような値を data 属性値に利用するのは避けたほうが良いだろ
う。

4. ほか
data 属性2/2
<div id="hoge" data-piyo="fuga">aaa!</div>
<script>
console.log(document.getElementById('hoge').dataset.piyo)
</script>
<style>
div::before {
content: attr(data-piyo);
}
</style>
console には fuga と表示され、画面には fugaaaa! と表示される。

4. ほか
WAI-ARIA 1/2
Web Accessibility Initiative - Accessible Rich Internet Applications の略。
role や aria-* 属性により、HTML をセマンティック（意味論）に意味を持たせる目的の
仕様のことで、主に読み上げブラウザを必要とするユーザへのユーザビリティの担保と、
一部クローラビリティにも寄与するであろうもの。
role がコンテンツの役割を意味するもので、これは HTML5 で登場した新タグ群と超複数
する意味を持つものも含む。タグと同等の意味を持つ role タグの付与は非推奨とされてお
り、HTML タグで既に同様の意味を持つものがある場合はタグを利用するのが推奨され
る。
aria-* は、要素の状態や性質を示すもので、要素の表示・非表示や選択・非選択を示す為
に使う。これらはユーザの操作や JavaScript 等により HTML の状態のみでは表現できな
い要素の状態を aria-* 属性で定義することで、ユーザビリティを担保する。
https://www.w3.org/TR/wai-aria-implementation/

4. ほか
WAI-ARIA 2/2
WAI-ARIA は、ブラウザで網羅的に実装されている機能でもなく、実装コストも低くな
く、実装メリットも見えにくい部分だが、様々なユーザが訪れる大規模サイト、特に利用
頻度が高いサービスであれば、実装は CSR 的にも重視されるべきだと考える。
ネット上のアクセシビリティとしては 2004 年に JIS X 8341-3（「やさしいさん」と読め
るとのことで…）として「高齢者・障害者等配慮設計指針－情報通信における機器，ソフ
トウェア及びサービス－第3部：ウェブコンテンツ」が制定され、特に銀行系の Web サー
ビスで Web サービス利用ガイドラインと共に実装が進んだ。これは個人的には W3C メン
バーでもあるとある企業の推進が大きかったのではないかと想像するが、それ以降実装が
一般的に浸透したかと問われると… 企画視点で言えばいくつかの配慮でユーザとのエンゲ
ージメントを高める為の大きな手段とも言えるだろう。

4. ほか
SVG
Scalable Vector Graphics の略。
デジカメで撮った写真等がいわゆるドットの集合であるのに対し、
点と点が線で結ばれ、各点が持つ二本の接線ハンドルと呼ばれるハンドルで先の向きを調
整するいわゆるベクターデータ形式を Web で扱えるようにする為のファイル形式であ
り、タグ。
線と塗りで表現できるような画像の利用に向いており、拡大しても像が荒れず、およそフ
ァイルサイズも小さくなるが、描画処理コストは高いので、大量の SVG が動き回るような
処理はブラウザによっては後負荷を引き起こすことになりかねない。
利用方法は様々だが、読み込みスピードや同一ページ内での利用頻度や管理コスト等を加
味して最低な利用手法を検討するのが望ましい。
SVG ファイルを img タグで参照
svg タグを直接 html に設置
非表示にした svg タグを読み込み、設置したい箇所の svg タグから参照（複数箇所の
設置に向いている）

2018年に於ける HTML の役割（実践編）

Recommended

More Related Content

Similar to 2018年に於ける HTML の役割（実践編） (20)

2018年に於ける HTML の役割（実践編）