Zusammenfassung

  • Der erste öffentliche W3C-Entwurf von 2015 benutzte für ein Rezept document.keepScreenAwake. Das Dokument meldete einen Wunsch; der Browser ordnete ihn dem sichtbaren Tab und dem Zustand des Betriebssystems zu.
  • Die Kandidatenempfehlung von 2017 behandelte Bildschirm- und Systemsperren gegen den Ruhezustand. Seit 2020 beschreibt ein bildschirmspezifischer Entwurf eine Anfrage samt freigebbarer WakeLockSentinel, die von Sichtbarkeit und Energieversorgung abhängt.

Die automatische Bildschirmsperre ist gewöhnlich ein verlässlicher Sparmeister. Beim Kochen kann sie zum Komiker werden: Das Wasser kocht, Mehl klebt an den Fingern, und ausgerechnet die Zeile mit der Backzeit verschwindet. Eine Rezeptseite hat einen guten Grund, um mehr Zeit zu bitten. Das Tablet hat ebenfalls einen Besitzer und einen Akku. Die Webseite muss jemanden fragen, der tatsächlich über die Energie entscheidet.

Der erste öffentliche Wake-Lock-Entwurf des W3C vom 12. Februar 2015 begann mit einem Rezeptbeispiel. document.keepScreenAwake wurde auf true gesetzt und nach Ende des Bedarfs wieder auf false. Diese Zeile sah nach einem Schalter im Eigentum der Seite aus. Im Text war es ein Anforderungsflag des Dokuments. Der Browser prüfte, ob die Seite im Vordergrund und relevant war, und bat dann das Betriebssystem um den entsprechenden Zustand, sofern das Gerät ihn erlaubte. Das Rezept stellte einen Antrag; den Schlüssel zum Akku bekam es nicht.

Schon 2015 hatte der Tabwechsel Folgen. Sobald der Leser etwas anderes ansah oder das Browserfenster verließ, verlor die Rezeptseite ihren Anlass, das Display weiter zu beleuchten. Der Browser verknüpfte Anträge mehrerer Dokumente mit der tatsächlichen Nutzung. Eine seit dem Frühstück vergessene Seite sollte nach dem Abendessen keine elektrische Nachtschicht anordnen können.

Die Kandidatenempfehlung vom Dezember 2017 fasste zwei Arten von Wachheit zusammen. Eine hielt den Bildschirm an, damit Text sichtbar blieb; eine andere betraf das Weiterarbeiten des Systems bei dunklem Display. Ein Bäcker will die Anleitung sehen. Eine Hintergrundberechnung will Prozessorzeit. Der Entwurf beschrieb Anforderungsobjekte sowie automatische Wechsel, wenn die Seite verborgen wurde oder das Gerät andere Prioritäten hatte. „Wach bleiben“ war bereits eine zu grobe Überschrift für zwei verschiedene Stromrechnungen.

Der Screen-Wake-Lock-Entwurf vom September 2020 zog eine engere Grenze um den Bildschirm. Sichtbare Dokumente konnten eine Anfrage stellen und eine WakeLockSentinel erhalten. Sie konnten diese freigeben und erfahren, wenn sie freigegeben wurde. Ein niedriger Akkustand, ein Sparmodus oder ein unsichtbarer Tab konnten den Handel beenden. Das ist eher ein ausleihbarer Arbeitsstrahler als eine lebenslange Beleuchtungsgarantie.

Die Publikationsgeschichte des W3C verbindet den ersten Entwurf von 2015, die Kandidatenempfehlung von 2017, den gesonderten Bildschirmtext von 2020 und spätere Fassungen. Die Reihe zeigt, wie der Anspruch präziser wurde. Aus einer allgemeinen Bitte gegen den Schlafzustand wurde ein zeitweiser Wunsch nach sichtbarem Inhalt, den Gerät und Benutzer zurückweisen können.

Im Entwurf vom September 2026 muss das Dokument sichtbar sein. Berechtigung und Richtlinie können die Funktion begrenzen; Browser und Betriebssystem können sie freigeben oder unter Energieknappheit unanwendbar machen. Eine manuelle Abschaltung des Bildschirms hat Gewicht. Der Antrag an das Betriebssystem gilt als beratend. Die Webseite kennt den Inhalt des Rezepts, das Gerät kennt seine Batterie.

Die interessanteste Entscheidung trifft trotzdem der Betreiber der Seite. Licht während des Knetens ist hilfreich. Nach Ende des Backens kann die Anfrage weg. Wer das Display für Werbezeit wach hält, verwendet dieselbe Technik für einen anderen Zweck. Die Schnittstelle schreibt keine Tischmanieren vor, aber sie verrät, wer die Stromrechnung seinem Gast überlässt.

Der Teig ist noch nicht fertig. Das Tablet darf um ein paar Minuten bitten. Wenn der Akku Feierabend macht, muss das Rezept einen anderen Weg zum Leser finden.