要約

  • 2015年の W3C 初公開草案は、レシピの例で document.keepScreenAwake を用いた。文書は希望を示し、ブラウザーが表示中のページと端末の状態を踏まえて OS に依頼する。
  • 2017年の勧告候補には画面とシステムの二種類があった。2020年以降の画面専用草案では、要求と解除できる WakeLockSentinel を使い、可視性や省電力状態によって継続が左右される。

自動消灯は普段、気の利く節約係だ。ところが料理中は、鍋を見張り、粉のついた指で生地をこねている真ん中でレシピを隠してしまう。ページ側には明かりを求める理由がある。端末側には電池を守る理由がある。片方だけが命令書を持っていたら、この小さな衝突はうまく収まらない。

2015年2月12日の W3C 初公開草案は、まさにレシピを例にした。表示中は document.keepScreenAwake = true、用が済めば false。一行だけ見るとページが電源スイッチを握ったように見える。本文では文書が保持するのは要求フラグで、ブラウザーが前面にいる文書を見て OS に働きかける。OS の状態が許さなければ適用されない。レシピは申し込めるが、電池の所有者にはなれない。

草案が前面の文書を重視したのは実用的だ。料理を中断して別のタブへ移った後も、古いレシピのために画面を照らし続ける必要はない。ブラウザーは複数ページからの頼み事をまとめ、今どれが利用者の前にあるかを判断する。ページ自身が「まだ開いているから必要だ」と言い張っても、その声だけで明かりは続かない。

2017年12月の勧告候補では話が広がった。画面を消さないためのロックと、画面が消えても処理を続けるためのシステムロックを区別する。料理人が欲しいのは読める表示だ。裏で計算を続けたいアプリが欲しいものとは違う。要求オブジェクトや、可視性と端末条件に応じた自動管理も記された。「起きていて」と頼む相手は一つでも、何を起こすのかで電力の勘定は変わる。

2020年9月の Screen Wake Lock 草案は画面そのものに絞った。見えている文書が要求を出し、解除できる WakeLockSentinel を受け取る。画面の必要がなくなれば返せるし、ブラウザーや端末の事情で解除されたことも知れる。電池残量や省電力設定、タブが隠れたことは交渉の条件だ。借りた作業灯には返却口がある。

W3C の公開履歴には2015年の初稿、2017年の勧告候補、2020年の画面専用草案、その後の改訂が並ぶ。どの日付も仕様書の発行日である。流れとして面白いのは、広い「休止させない」から、対象と条件がはっきりした画面の要求へ言葉が絞られたことだ。

2026年9月の草案でも、文書は表示中でなければならず、許可や方針、ブラウザー、OS の判断が関わる。電池が乏しい時や省電力モードでは解除され得る。人が手で画面を消す選択も重い。OS への取得要求は助言的なものとして扱われる。レシピにできるのは理由を告げることだ。

ウェブサイトの振る舞いも問われる。読者が手順を追う間だけ明かりを借り、終わったら返すなら親切だ。読者が台所を離れた後も広告のために照らし続けるなら、同じ API が別の顔を見せる。どこで頼み事をやめるかはページの設計者が決める。

生地はまだ待っている。画面が光ってくれれば助かる。電池が閉店を告げたら、レシピも店の都合を聞くしかない。