Summary

  • Le projet de travail Page Visibility publié par le W3C le 2 juin 2011 donnait à une page un état de visibilité et l’événement visibilitychange pour réagir aux changements.
  • Son exemple de messagerie était très concret : vérifier l’arrivée de courrier toutes les quelques secondes lorsque l’onglet est visible, puis toutes les quelques minutes quand il est caché. L’application choisissait la fréquence.

La boîte mail travaille toute seule derrière six onglets. Son propriétaire lit un rapport, fait ses comptes ou prépare le déjeuner. Elle, consciencieuse jusqu’à l’absurde, demande encore et encore au serveur s’il y a du nouveau. C’est un facteur qui sonne toutes les dix secondes à une maison vide. À l’échelle de plusieurs pages, cette sollicitude finit par coûter du temps de calcul et de l’énergie.

Le projet Page Visibility daté du 2 juin 2011 partait de cette lacune. Le navigateur savait si un document se trouvait au premier plan, dans un onglet d’arrière-plan ou dans une fenêtre réduite. La page, elle, ne disposait pas d’un signal simple pour adapter son comportement. document.hidden, un état de visibilité et l’événement visibilitychange ont fait passer cette observation d’un côté à l’autre de la fenêtre.

L’exemple choisi par les auteurs ressemblait à la vie ordinaire d’un navigateur. Une messagerie visible pouvait interroger son serveur toutes les quelques secondes. Cachée, elle pouvait espacer les vérifications à quelques minutes. Le serveur recevait moins de demandes pendant que personne ne regardait le résultat, et la page pouvait redevenir empressée au retour du lecteur. Le standard transmettait l’information; le service fixait la cadence adaptée à ses messages.

La proposition envoyée en janvier 2011 sur la liste publique du W3C imaginait également un jeu de réflexion dont le chronomètre s’arrête quand l’onglet disparaît, des vérifications périodiques qui ralentissent, ou une vidéo qui attend d’avoir un spectateur. La diversité de ces cas est instructive. Le navigateur constate une même chose — la page est cachée — tandis que chaque application en tire une conduite qui lui appartient. Le jeu protège son joueur; la messagerie ménage ses requêtes; la vidéo attend son public.

Le projet précisait ce que « caché » voulait dire. Un onglet à l’arrière-plan, un navigateur réduit ou un écran verrouillé figuraient parmi les exemples. Un document visible, même en partie, restait visible. Le texte ménageait aussi le cas d’un outil d’accessibilité qui recouvre l’écran tout en montrant la page agrandie. On cherchait une observation de l’affichage réel, plus pertinente qu’une simple supposition tirée des événements de focus et de perte de focus.

L’événement visibilitychange faisait de cette observation une information vivante. Lire l’état une seule fois à l’ouverture ne suffit pas quand le lecteur passe au rapport, revient à sa messagerie et s’en va de nouveau. L’application peut modifier son programme au passage de chaque frontière. Le projet de dernière consultation de juillet 2011 conservait les usages concrets en affinant l’interface. Le navigateur indiquait ce qu’il voyait; la page décidait quoi faire de cette connaissance.

La Recommandation du 14 mai 2013 formalisa hidden, visibilityState et visibilitychange, avec des états supplémentaires prévus pour certaines situations comme le prérendu ou le déchargement. La seconde édition du 29 octobre 2013 porte une correction étonnamment modeste : une faute dans le nom de visibilitychange à la section 4.3. Des années de travail pour expliquer quand une page est regardée, puis un dernier passage pour écrire correctement le nom de l’événement. Les normes aussi ont leur relecteur.

Cette histoire croise celle des Web Workers sans la répéter. Un worker offre un autre espace d’exécution à un calcul long. Page Visibility donne à l’application une raison de travailler moins souvent quand sa page a quitté le regard du lecteur. La messagerie pourrait utiliser les deux : un calcul dans un worker, et un rythme de vérification ralenti dans l’onglet caché. L’emplacement du travail et le moment où il vaut la peine de le faire sont deux décisions distinctes.

Le projet parlait d’économie de processeur et d’énergie comme d’un objectif, à partir d’un geste très humain. On peut laisser une pièce sans demander au facteur d’y sonner aussi souvent qu’avant. Le navigateur signalait que la pièce était vide. La messagerie recevait enfin l’occasion de se comporter en conséquence.