第39話で、イトは切りすぎたURLをつなぎ直した。
三つのprojectorは、同じstandby programを待っている。
browser工房へ、最初のresponseが届いた。
Content-Type: text/html body: program document
イトは、箱の中をのぞいた。
見出しらしい文字。
link、script、imgという印。
山形の記号に挟まれた短い名前。
完成した星の画面は、どこにもない。
「serverが、作りかけを送ってきた」
会場screenを確認するまで、四十八秒。
イトはresponseの箱を「完成画面待ち」のslotへ置いた。
工房のparserを止める。
追加resourceを受ける三つのshutterも閉じた。
「完成したpageが届くまで、これ以上動かさない」
responseは届いた。でも、screenにならない
待機lampは青い。
network errorも出ていない。
それでも、三つのprojectorは暗いままだ。
inspection screenには、HTMLの文字列だけが流れている。
response received document processing: paused rendered frame: none
残り、四十一秒。
イトはresponse箱を持ち上げた。
「届いているのに、どうして画面じゃないの？」
ピコは、完成画面待ちslotと、その奥で止まった工房を同時に照らした。
イト
browserは、serverから完成したpageを受け取って映すんじゃないの？
ピコ
受け取ったresponseを解釈し、documentを作ってrenderするところにもbrowserの仕事がある
イト
このHTMLは、不良品じゃなくて組み立てを始める入力？
ピコ
このfixtureではそう。しかも、HTMLが別resourceを参照している
browserとsearch serviceは、同じ箱ではない
イトは、address barの模型を見た。
文字を入れると検索結果が出ることもある。
だから、browserは検索するserviceだと思っていた。
でも役割は分けられる。
browserは、Web resourceへnavigateし、responseを処理し、documentを表示・操作するuser agentだ。
search engineは、queryに合う情報やURLを探すserviceだ。
browserのaddress barからsearch serviceを使う場合はある。
検索結果のlinkを選んだあと、そのURLへnavigateしてpageを処理するのはbrowserだ。
同じ窓から始まっても、探すserviceと、開いて処理するapplicationは同じ役割ではない。
今回は検索結果を作る話ではない。
ep39で確定したURLから返ったresponseを、screenへ変える話だ。
HTMLは、完成pixelではなくdocumentの入力になる
イトが止めた最初の台は、HTML parserだった。
WHATWG HTML Living Standardでは、text/html resourceの入力はcode pointのstreamとしてparserへ入る。
tokenizationを通り、tree constructionへ進み、Document objectができる。
WHATWG DOM Standardは、markup-based documentをnode treeとして表すmodelを定めている。
見出し、本文、link、button、画像位置は、ばらばらの文字列のままではない。
親と子を持つnodeのtreeとして扱えるようになる。
よくDOM treeと呼ばれるものだ。
ただし、HTMLとDOMは同じ文字列ではない。
HTML parserは、入力を読んでDocument treeを作る。
scriptがあとからnodeを追加・変更することもある。
「HTML箱をscreenへ貼るんじゃない。まず、documentとして読める形にする」
イトは、止めたparserの歯を手で回した。
まだleverは戻していない。
HTMLの中には、別resourceへの参照もある
tree construction lampの先で、三枚のrequest cardが点滅した。
fixture用のstylesheet。
星のposter image。
screen切替用のscript。
HTMLには、文章やstyleやscriptをinlineで含める場合もある。
別URLのresourceを参照する場合もある。
画像もscriptも使わないpageはある。
だから、すべてのpageに「HTML、CSS、JavaScript、画像の四箱」が必ず別々に届くわけではない。
今回のdocumentは、三つを外部resourceとして参照していた。
イトがshutterを閉じたため、request cardだけが出口で止まっている。
HTML Standardのexternal resource linkには、link typeごとにresourceをfetchしてprocessするmodelがある。
stylesheet linkなら、supportするtypeやmedia等の条件を見て処理される。
見つけたものを全部、無条件で同じ方法により開くわけではない。
CSSは、treeの見た目に使う値を決める
amberのrequest cardは、stylesheetを指していた。
HTML treeだけでも、見出しと本文の関係はある。
でも、このfixtureでは会場screen用の色、余白、配置が別stylesheetにある。
CSS Cascading and Inheritance Level 5は、複数のstyle ruleをcollateし、cascadeとinheritanceを通して各elementのproperty valueを決める仕組みを定める。
authorのCSSだけが唯一のruleではない。
user agentのdefaultやuser側のstyle等もcascadeへ関わり得る。
viewport、font、device、user preference等で、最後の見え方が同じpixelになるとは限らない。
CSSは完成画面の写真ではない。
structured documentをどうrenderするか決めるruleだ。
imageは、場所だけでなく別の取得とdecodeを持つ
cyanのrequest cardは、星のposterを指していた。
HTMLのimg elementには、画像を置く場所とsource候補がある。
でも、画像dataそのものがHTML response内に必ず入っているわけではない。
HTML Standardのimg elementでは、source selection、request、decode、renderingとの関係が別に扱われる。
sourceが使えない場合は、altの有無や値、user agentの設定等によってtext replacementやindicatorになる場合もある。
今回のscreenにはposterが重要だ。
だから、画像requestを止めたままでは星のframeが空く。
scriptは、いつも同じ順番で動く道具箱ではない
greenのrequest cardは、screen切替用scriptを指していた。
HTML Standardのscript elementは、dynamic script、user agentへのinstruction、data blockをdocumentへ含められる。
srcがあれば、外部scriptを指定URLからfetchする形もある。
scriptはDOMを読み、nodeやattributeを変更し、eventへ反応できる。
ただし、JavaScriptがなければWeb pageにならない、とは限らない。
staticなdocumentはHTMLとCSSだけでも表せる。
scriptにはclassic / module、inline / external、async / defer等の違いがある。
parserやrenderを待たせる場合も、別の時点で動く場合もある。
「HTML、CSS、JavaScript、画像を必ず一箱ずつ、この順に組む」という説明では足りない。
browserは、documentと各resourceのrule、取得状態、実行条件を合わせて処理する。
イトの前に、三つの起動方法が開く
工房の確認bellが鳴った。
残り、二十五秒。
完成画面待ちslotの横に、三つのleverが出た。
A serverから完成screenが届くまで待つ
最初のHTML responseは届いている。
このfixtureでは、完成pixelを返す二通目のresponse予定はない。
待っても工房は動かない。
B HTMLの文字列をinspection screenへ貼る
response bodyは見える。
でもDocument tree、stylesheet、image、interactionを処理しない。
inspectionには使えても、会場用pageの代わりにはならない。
C HTMLをparserへ戻し、documentが参照したresourceを処理する
HTMLからDocument treeを作る。
fixtureが参照するstylesheet、image、scriptのrequest shutterを開く。
各resourceのruleと状態に従って処理し、screenをrenderする。
ピコは、leverの答えを言わなかった。
「全部の箱を開けばいい？」
イトは、工房の外に積まれた無関係な箱を見る。
次に、Document treeから伸びた三枚のrequest cardを見る。
「違う。今のdocumentが参照し、工房が処理すると決めたものを通す」
イトはCを選んだ。
完成画面待ちslotからHTML responseを抜く。
自分の手でparserのinputへ差し戻した。
次に、Document treeから出た三枚のrequest cardを確かめ、閉じたshutterを開いた。
一枚のresponseから、screenが変わっていく
parser lampが回り始めた。
文字のstreamがtokenへ分かれる。
tree construction railに、見出し、program list、button、image elementが並ぶ。
最初のprojectorに、飾りのないstructureが現れた。
document tree: ready referenced resources: processing
amber lampが点く。
stylesheetのruleがelementへ適用され、見出しの大きさ、余白、色、二列の配置がscreenへ現れた。
cyan lampが点く。
decodeされた星のposterが、空いていたimage frameへ入る。
green lampが点く。
イトが「会場screen」buttonを押すと、scriptがprogram listの表示stateを切り替えた。
三つのprojectorが、同じstandby programを映す。
残り、九秒。
イトはもう一度buttonを押した。
三つとも、受付用の補足へ戻る。
もう一度押す。
三つとも、会場用screenへそろう。
rendered frame: visible interaction: observed
ここでstructure、style、image、scriptが現れた順番は、このfixtureの観察結果だ。
すべてのWeb pageが同じ順で完成する保証ではない。
resourceは並行して取得・decodeされる場合がある。
cache等から使われ、network requestが起きない場合もある。
scriptやstylesheetがparser / renderingを待たせる条件もある。
browserの仕事は、四箱を決まった順で積む単純なconveyorではない。
responseとscreenの間を消さない
確認時計が止まった。
イトは、完成画面待ちslotを工房から外した。
raw HTML responseの箱は捨てない。
renderされたscreenの真下へ置く。
二つの間には、parser、Document tree、resource request、style、script、image decodeのlampが残った。
screenに見えているものは、serverの箱をそのまま写した写真ではない。
browserが、受け取ったものと現在の環境を合わせて作った結果だ。
星のposterの下で、buttonがもう一度光った。
raw responseの箱には、まだ完成画面は入っていなかった。
次回：最初のrequestは、どこへ送る？
工房を出ようとしたイトの前で、URL札が止まった。
festival.example
文字のhost名は読める。
でも、networkのaddress欄は空白だ。
「名前だけで、packetは相手へ着けるの？」
ピコが、名前案内所のlampをつけた。
次回、ピコルート第41話。
DNSは名前をどう案内する？
browserの役割を図で確かめる
search engineとの違い、HTML / CSS / JavaScriptとの関係、pageが開かないときの切り分けを整理するなら、ブラウザとは何かで確認できます。