仕様上のタイミング
[15] navigate によって fetch が実行され、それを HTML
として処理することが決定されると、 Document
が作られ、 HTML構文解析器と関連付けられます。
この Document の作成よりは後であって、
しかしスクリプトの実行や、 stop parsing よりも前に、
update the session history with the new page が実行されることになっています >>14。
どの要素が現れた後、といったような厳密なタイミングは規定されていません。
[17] update the session history with the new page は、
Document を前の文書のものから >>15 の新しく作成したものに交換します
>>16。
[18] Document が交換されると、次のレンダリングの更新のタイミング
(明確に規定されているものに限れば、イベントループ中のレンダリング更新ステップの、
次の実行時) には、viewport に反映されることとなります。
[19] この update the session history with the new page はタスクをキューに入れることによって非同期的に実行されますし、
update the session history with the new page が行われる (構文解析に対する)
タイミングも厳密には決められていませんから、 Webブラウザーはそれぞれの好きなタイミングで新旧文書を入れ替えられることになります。
[21] ただしスクリプト実行前という制約があるので、
当該文書内のスクリプトが実行される時には、
必ずレンダリングが始まっていることになります。
他の文書のスクリプトからも、新しい Document
にアクセスできるようになるタイミングとレンダリングが更新されるタイミングが >>18
の通り同時なので、レンダリングが始まる前の文書にアクセスすることはできません。
[22] 当該文書内のスクリプトは、
その実行時点で必ずレンダリング開始されていることになっているので、
どの時点からレンダリングが開始されていたか判定することはできません。
他の文書からは、 (レンダリングを直接観測することはできませんが)
Document にアクセスして DOM
がどんな状態になっているか調べることで、どの状態からレンダリングが開始されたか推測はできます。
[23] スクリプトから観測可能なのに仕様上明確に定められていなくても大丈夫なのかと思うかもしれませんが、
元々ネットワークの状態により DOM が完成するまでの速度は違うものですから、
いつからアクセス可能になるかの厳密なタイミングに依存するようなスクリプトが存在することは困難で、
明確に定義されなくても相互運用性上問題無いのでしょう。[24] ただ、 iframe 内に document.write
して document.close するよりも前でいつレンダリングが開始されるかのように、
利用者に観測可能な形でスクリプトの見た目上の動作が変わってしまうことが実際にあります。
(そのような document.write の使い方は近年では稀ですが。。。)
[20] UI は仕様の対象外となっていますが、タイトルバーと viewport
で違う文書の情報を表示しているような状態が存在する実装は、仕様の趣旨に反しているかもしれません。