Summary

  • W3Cが2011年6月2日に公開したPage Visibility作業草案は、ページが自分の可視状態を読み、visibilitychangeで変化を知る方法を示した。
  • 草案の例では、見えているメール画面は数秒おきに新着を確認し、隠れたら数分おきに間隔を延ばせる。確認の頻度を決めるのはアプリケーションだ。

メールのタブは、地図と記事と買い物かごの後ろにいる。持ち主は別のことをしているのに、メール係はまた郵便受けを開ける。数秒後にもう一度。誰もいない窓口で呼び鈴を鳴らし続けるようなものだ。裏で働くページがいくつもあれば、律儀さの勘定は処理時間と電力に回ってくる。

2011年6月2日のW3C作業草案は、ブラウザーが既に持つ情報をページへ渡そうとした。どのタブが前にあるか、ウィンドウが最小化されたか、文書が画面に映っているか。ページはdocument.hiddenと可視状態を読み、visibilitychangeで変化を受け取る。ブラウザーが見えている事実を知らせ、ページが仕事の予定を変える。

草案が挙げたのはウェブメールだった。読者が受信箱を見ているなら、数秒おきにサーバーへ新着を聞く。別のタブへ移ったら、数分おきへ落とす。どの知らせに急ぐ価値があるかはメールサービスが判断する。画面に人がいるかどうかはブラウザーが分かる。双方が自分の持ち場の情報を出せば、見られていないページも前面と同じ忙しさで走り続けずに済む。

その発想は2011年1月のW3C公開メーリングリストの提案にも現れている。隠れたパズルの時計を止める、定期的な問い合わせを休ませる、初めてタブを開くまで動画を始めない。受け取る合図は同じでも、行動は違う。ゲームはプレーヤーの時間を守り、メールは問い合わせを節約し、動画は観客を待つ。

「隠れている」の意味も具体的に書かれた。背後のタブ、最小化されたブラウザー、ロックされた画面が例に挙がる。文書の一部でも画面に見えていれば可視と扱う。画面を覆うような拡大ツールを使っていても、その道具を通してページを読める場合に配慮した。ページが焦点の出入りだけから推測するより、ブラウザー自身の表示状態を使うほうが筋が通る。

可視状態は一日中動く。最初に一度だけdocument.hiddenを読むと、読者がメールから地図へ移り、また戻ってくる時間を扱えない。visibilitychangeは切り替わるたびにアプリケーションへ知らせる。2011年7月の最終意見募集草案も、生活感のある使用例を残しながらインターフェースを整えた。共通の合図は小さいが、応答する機会は何度でも来る。

2013年5月14日のW3C勧告にはhidden、visibilityState、visibilitychangeが並び、画面外での事前表示や文書の終了に関わる状態も条件付きで記述された。同年10月の第二版勧告の変更点は実に人間らしい。第4.3節のvisibilitychangeというイベント名の誤字を直しただけだった。ページが見えているかどうかを決める規格も、最後には校正者の目を必要とした。

この話はWeb Workersとも役割が違う。Workerは長い計算の置き場所をページの応答処理から分ける。Page Visibilityは、今その作業をどれほど頻繁に行うべきかを判断する材料になる。メールの画面は計算のためにWorkerを使いながら、隠れたら新着確認を遅くすることもできる。仕事の住所と勤務時間は別々に決められる。

2011年の草案はCPUと電力の効率を目標として掲げた。けれども仕組みは日常の常識に近い。部屋に誰もいなければ、郵便係が数秒おきに扉をたたく必要はない。ブラウザーは部屋が空いたと知っていた。その知らせがようやく、働き続けるタブへ届いた。