画面は、白かった。
送別会の開始まで、あと三分。
今日、イトの同級生が遠い町へ引っ越す。
出発前に話せるのは、この一回だけだ。
イトは送別ページを徹夜で作った。
三百枚の星空アニメーションが流れたあと、二人の写真と「通話を開く」リンクが現れる。
何度も試した。星の速さも、夜空の色も、最後の一枚まで決めた。
HTTPの返事は、もうブラウザへ届いている。
それなのに、画面には一つの星も、リンクも、文字もない。
白い光だけが、イトの顔を照らしていた。
返ってきたのは、完成画面ではない
ピコがHTTPの封筒を開いた。
中には、完成した送別ページの写真は入っていない。
HTMLの文字列。
CSSの規則。
星空の画像ファイル。
演出を始めるJavaScript。
ブラウザは、それぞれを読み、画面へ組み立てる。
サーバーが完成画面を一枚送るのではない。
WHATWG HTML Standardには、HTMLをtoken（読み取り単位）へ分けてdocument tree（文書の木構造）を組み立てるparsing algorithmが定められている。
この木構造は、見出しの下に段落があり、その中にリンクがある、といった関係をブラウザが扱う土台になる。
DOM Standardも、documentを相互につながるnodeのtreeとして扱う仕組みを定めている。
ただし、DOMの木構造はまだ完成画面ではない。
そこへ、どの文字を大きくするか、どこへ余白を置くか、何を隠すかというCSSの規則が重なる。
HTMLには、もう別れの言葉があった
ブラウザ工房の透明な台へ、HTMLの木構造が浮かんだ。
一番上に見出し。
その下に短いメッセージ。
最後に、通話先へ進むリンク。
必要な内容は、すでに届いている。
けれど、画面は白いままだ。
ユイが、木構造と画面を見比べた。
ユイ
文字もリンクも届いているのに、どうして何も見えないんですか
マコト
出発まで二分四十秒。通信の返事だけを待っている状態ではなさそうだね
ピコ
CSSの中に、画面全体を隠す規則が一つあるよ
イト
星空が始まるまで、途中のページを見せたくなかったんだ
作業台の上で、赤い規則が光った。
body {
visibility: hidden;
}イトが自分で入れた規則だった。
星空アニメーションの準備が終わったら、JavaScriptが非表示を外す予定だった。
しかし、三百枚の画像ファイルはまだ届いていない。
JavaScriptは星空を待つ。
CSSはbodyを隠す。
HTMLにある別れの言葉も、通話リンクも、一緒に白紙の下へ隠れた。
ブラウザは、隠す規則も守っていた
CSSは、構造を持つdocumentを画面などへどう描くかを表す言語だ。CSSOMは、style sheetやCSS ruleをobjectとして扱う仕組みを定めている。
ブラウザ工房では、HTMLの木構造とCSS ruleの札が重なった。
見出しには大きな文字。
リンクには青い枠。
そしてbody全体には、非表示。
ブラウザはイトの気持ちを読んで、必要な規則だけを選ばない。
書かれた規則を解釈した結果、ページ全体を見えなくしていた。
「壊れているんじゃない」
イトは白い画面を見た。
「僕が、隠すように頼んだんだ」
送別会まで、あと一分五十八秒。
イトが選べる三つの道
ピコが三枚の札を置いた。
- このまま待つ
- 写真を映す
- 非表示を外す
一枚目なら、三百枚の星空が届くまで待てる。けれど、相手の出発時刻が先に来るかもしれない。
二枚目なら、完成時に撮ったスクリーンショットを一枚映せる。星空の最後は見えるが、画像の中の通話リンクは押せない。
三枚目なら、bodyを隠す規則と星空を待つscriptを外せる。HTMLのメッセージとリンクは描けるが、徹夜で作った演出は一度も相手に見せられない。
イトは床に並ぶ三百枚の星を見た。
最初の一枚は、真っ暗な空。
最後の一枚では、二人の町を結ぶ光が一本になる。
そのために、夜を使い切った。
画面の向こうでは、相手の接続ランプが点滅し始めた。
イトは、星空を描画から外した
送別会まで、あと一分二十二秒。
イトは赤い非表示の規則を、CSSの台から引き抜いた。
次に、星空を待つJavaScriptの札を外す。
三百枚の画像ファイルは、工房の床へ置いたままにした。
「内容とリンクを、先に出す」
イトが、再描画のレバーを自分で倒した。
ブラウザがstyle（見た目の規則）を計算し直す。
見出し、メッセージ、リンクが持つboxの大きさと位置を決める。
白い画面へ、文字と枠を描く。
画面の変化に必要な仕事は、変更内容によって異なる。ブラウザのrenderingでは、style、layout（配置計算）、paint（描画）などのstepが関わり、すべての変更が毎回まったく同じ道を通るわけではない。
この工房の札は、複雑なブラウザ内部を初学者向けに見える形へしたものだ。
白紙に、三つだけ現れた
最初に、見出しが出た。
次に、短いメッセージ。
最後に、青い通話リンク。
背景は白い。
星はない。
写真も動かない。
イトがリンクを押す。
画像ではなく、本物のリンクが通話先を開いた。
小さな通話窓に、同級生の顔が映る。
出発まで、あと五十二秒。
イトは用意していた長い言葉を忘れた。
「元気で」
相手が笑った。
それから、窓の向こうで大きく手を振った。
使える画面と、きれいな完成図は違う
見た目が完成していても、必要な内容と操作が届かなければ、使える画面にはならない。
スクリーンショットなら、三百枚目のきれいな夜空は見せられた。
けれど、画像の中のリンクから通話は開けない。
飾りのないHTMLだけでも、ブラウザが木構造を作り、規則を合わせ、位置を決め、描けば、人が読んで操作できる画面になる。
これは、見た目を軽視するという意味ではない。
どの材料を最初の表示に必要とするか、何を待つか、何を隠すかが、利用者の最初の一秒を変えるということだ。
通話窓が閉じた。
工房の床には、使われなかった三百枚の星空のコマが残った。
白い送別ページには、押されたあとのリンクと、短いメッセージだけがある。
イトは星空を再生しなかった。
遠ざかる車の小さな窓で、相手がもう一度手を振った。
未使用の星は、白い画面の青光だけを受けていた。
次回：HTMLは、役割をどう書く？
送別ページの見出し、メッセージ、リンクは、星空がなくても残った。
けれど、ブラウザはどうして、一つを見出し、一つを段落、一つをリンクだと分けられたのか。
ピコがHTMLの木構造から、最初の札を一枚外した。
札の両端には、山かっこのような記号がある。
「これが、役割を伝える印？」
次回、ピコルート第8話。
HTMLは、ページの骨組みをどう書く？
ブラウザが画面を作る流れを確かめる
物語で見たHTML、DOM、CSS、layout、paintの関係を図で整理するなら、Webページ表示の仕組みでブラウザ内の流れを確かめられます。