Page Visibility API – Erklärung und Beispiele

Screenshot Google Code Page Visibility API

Schnell erklärt, die Page Visibility API

Inzwischen haben sich Tabs in Browsern durchgesetzt und werden von jedem Internet-Nutzer oft und gerne benutzt. Viele User schließen Websites wie Facebook, Google Mail oder weitere gar nicht mehr – sie lassen sie im Hintergrund weiterlaufen. Durch die HTML5 Visibility API ist es dem Webworker nun möglich abzufragen, ob die eigene Website gerade sichtbar bzw. unsichtbar für den Benutzer ist und ermöglicht es darauf zu reagieren.

Wofür kann man die Page Visibility API nutzen?

Gerade bei ajax- und medienlastigen Websites ist es keine Seltenheit, dass permanent Daten vom Server geladen werden, um die Seite, ohne das Eingreifen des Benutzers, aktuell zu halten. Mit der Page Visibility API kann verhindert werden, dass unnötige Requests abgesendet werden, wenn der Internet-User die Website gar nicht mehr im Blickfeld hat. Einige Beispiele für eine mögliche Anwendung:

  • Ein News-Portal auf dem alle 30 Sekunden via Ajax neue Nachrichten gepusht werden. Hat der User die Seite 15 Minuten im Hintergrund geöffnet, würde man dem Server durch die Nutzung der API 30 sinnlose Requests ersparen.
  • Ein Video auf YouTube wird abgespielt und der Nutzer verlässt den Tab. Es wäre möglich nun das Video zu stoppen und erst dann wieder abzuspielen wenn der User den Tab wieder aktiviert hat.
  • Eine Seite mit Bilder-Slideshow, die alle paar Sekunden vom Server neue Bilder bezieht und diese lädt. Es wäre nützlich dies zu stoppen, um dem User unnötigen Datentransfer zu ersparen, deren Ergebnis er ohnehin nicht sieht.

Wie teste ich ob meine Website gerade sichtbar ist?

Über die Variable document.hidden erfährt man ob die Seite gerade sichtbar ist. Man erhält entweder true oder false als Wert. Zu Beachten ist hier, dass es wie bei experimentellen CSS-Eigenschaften, Vendor-Prefixe gibt. Diese lauten für Webkit document.webkitHidden, für den Firefox document.mozHidden und für den Internet Explorer document.msHidden. Sofern der Browser die API nicht unterstützt wird als Wert undefined geliefert.

Detailliertere Informationen erhält man allerdings über document.visibilityState (Vendor-Prefixe document.webkitVisibilityState, document.mozVisibilityState bzw. document.msVisibilityState). Derzeit definierte Rückgabewerte sind:

  • visible
    Die Website ist zumindest teilweise sichtbar. Das bedeutet, dass sie zumindest in einem Browser gerade aktiv in einem Tab geöffnet wird und der Browser nicht minimiert ist.
  • hidden
    Die Website ist nicht sichtbar. Das kann zwei Gründe haben: Entweder ist im Browser gerade ein anderer Tab geöffnet oder das Browser-Fenster ist komplett minimiert.
  • prerender
    Der Inhalt der Seite wird noch vorgeladen und ist für den Benutzer noch nicht sichtbar. Die Website hat diesen Wert nur zu Beginn und kommt später nie wieder in diesen Zustand zurück.

Es wird ausdrücklich darauf hingewiesen, dass es hier noch mehr mögliche Rückgabe-Werte geben wird. Somit sollte man auch diese Funktion bevorzugen, um detailliertere Informationen zu erhalten.

Veränderungen des Benutzers bemerken

Via Event-Listener visibilitychange kann auf Änderungen der Website-Sichtbarkeit reagieren werden. Auch hier gibt es wieder Vendor-Prefixe: webkitvisibilitychange, mozvisibilitychange und msvisibilitychange. Ein einfaches Beispiel:


function handleVisibilityChange() {
if (document.hidden) {
pauseSimulation();
} else {
startSimulation();
}
}
document.addEventListener("visibilitychange", handleVisibilityChange, false);

 

Ein Beispiel wie das in der Praxis aussehen könnte gibt es hier (Chrome vorrausgesetzt). Einige weitere Code-Beispiele gibt es auf der Google Code Site zur API – Zwei Beispiele zeigen auch die Vorteile der Eigenschaft “prerender” (zum Beispiel das Zählen von Pageviews nur dann, wenn die Seite tatsächlich fertig geladen wurde).


Brauchen wir das und wo geht es jetzt schon?

Die API ist noch in einem sehr frühen Entwicklungsstadium. Folgende Browser unterstützen mit den genannten Vendor-Prefixen schon jetzt diese Funktionen: Chrome ab Version 13, Firefox ab Version 10 (Aurora) und der Internet Explorer auf Version 10 – Für Opera und Safari ist noch keine Implementierung bekannt (Stand 13. November 2011).

Für oben genannte Beispiele bietet die API einen starken Mehrwert und daher ist eine Implementierung in die eigene Website schon jetzt denkbar. Ältere Browser verhalten sich wie bisher, moderne bieten eine verbesserte Funktion. Ein klassisches Beispiel für Graceful degradation mit HTML5 – so soll es sein.

Weiterführende Links:

Dieser Artikel erschien in der Februar/März-Ausgabe des PHP-Magazins.

Battery Status Event – Erklärung und Beispiele

Screenshot W3C Battery-Status-Event

Ein Entwurf ist bereits verfügbar

Die Zeiten in denen Browser lediglich klassische Webseiten darstellen mussten sind längst vorbei. Das Internet rüstet sich für den nächsten großen Paukenschlag – Webapplikationen. Ein weiterer kleiner Schritt hin zum Browser und weg vom klassischen Betriebssystem ebnet das W3C mit dem Entwurf des Battery-Status-Events. Mit diesem soll es möglich sein, Abfragen über den Batterie-Zustand des vom Benutzer verwendeten Gerätes abzusetzen, eine Batterie-Anzeige nachzubauen und bei Bedarf auf Veränderungen zu reagieren.

Tolle Sache, wie funktioniert es?

Der Entwurf des Batterie-Status-Events ist noch sehr jung und eine Implementierung der Browserhersteller steht noch aus (Stand 13. Mai 2011) – Ein erstes Testen ist daher nicht möglich. Der voraussichtliche Funktionsumfang kann allerdings schon jetzt in der Spezifikation nachgelesen werden.

Die Attribute und Events

Über das window.batterystatus Objekt können künftig vier Informationen über die Batterie bezogen werden:

  • isBattery
    Nutzt der gerade verwendete Rechner überhaupt eine Batterie, dann wird true zurückgegeben. Ansonsten, beispielsweise bei einem Standrechner, false.
  • isCharging
    Sofern isBattery true ist, also der Rechner eine Batterie zur Stromversorgung nutzt, kann überprüft werden, ob das Gerät im Moment geladen wird. Auch hier wird true oder false als Rückgabewert verwendet.
  • level
    Mit diesem Attribut kann abgefragt werden wieviel Prozent Akku in der Batterie vorhanden ist – man erhält eine Zahl zwischen 0 und 100. Sofern der Zustand nicht ermittelt werden kann, liefert das Attribut null zurück.
  • timeRemaining
    Wieviel Sekunden der Computer mit dem derzeitigen Batterie-Stand noch ladefähig ist, kann man über dieses Attribut erfahren. Hier wird ebenfalls null zurückgegeben, sofern der Wert nicht ermittelt werden kann.

Für all diese Attribute gibt es auch Events, die sobald eine Änderung am Batterie-Status eintritt feuern. Bei level geschieht dies, wenn eine Änderung mit mindestens 1% vorliegt, bei timeRemaining wenn sich mehr als eine Minute seit dem letzten Aufruf verändert hat.

Wie bei jedem Event gibt es auch hier die Möglichkeit via addEventListener auf Ereignisse zu warten oder mit der window.onbatterstatus-Methode eine Funktion zu definieren, die bei einem Wechsel ausgeführt wird.

Beispiele

Aus mangelndem Browser-Support sind meine Beispiele eher als persönliche Interpretation der Spezifikation zu verstehen. Trotzdem ein kleiner Einblick einer möglichen Anwendung:

<script>
    window.addEventListener('batterystatus', function (event) {
        if(event.level < 3) {
            alert(“Ihr Akku neigt sich dem Ende, wollen Sie das Dokument speichern?”);
        }
        if(event.timeRemaining) {
            infoBox.innerHTML(“Sie können noch ” + (event.timeRemaining / 60)
+ ‘Minuten mit Ihrer Batterie arbeiten.’);
        }
    }, true);
</script>

 


Brauchen wir das überhaupt?

Ob Informationen über den Batteriezustand in einer Web-Applikation etwas zu suchen haben oder nicht, kann diskutiert werden. Es gibt allerdings Anwendungsfälle, die für Webentwickler interessant sein könnten. Sofern sich der Batteriezustand des Benutzers auf unter 3% bewegt, könnte man beginnen, einen Warnhinweis anzuzeigen bzw. die Benutzerdaten zu sichern, um Datenverlust zu vermeiden. Und seien wir ehrlich, so ein Batterie-Icon, gesteuert mit JavaScript, ist nerdig genug, um es zumindest einmal probiert zu haben! Mal sehen welcher Browser dieses Event zuerst implementiert. Sobald es Änderungen an dieser Front gibt, veröffentliche ich hier erste Real-Demos und weitere Informationen.