Résumé

  • Le projet de travail du W3C du 3 juillet 2012 permettait à un élément de demander le plein écran et au document d’en sortir, avec un calque supérieur et une sortie commandée par l’utilisateur.
  • En 2014, le W3C a cessé de travailler sur ce document et a renvoyé à WHATWG. Le standard actuel encadre l’entrée par une action récente de l’utilisateur dans le cas ordinaire, contrôle les contenus intégrés et exige une sortie toujours efficace.

Imaginons un festival de cinéma dirigé par des pages web. La vidéo demande l’obscurité, le jeu veut tout le mur et le diaporama trouve l’interface du navigateur particulièrement mal élevée. Le directeur de salle accepte. Puis le responsable du bâtiment pose une question moins artistique : qui ouvre les portes à la fin ? Une spécification d’affichage vient de se transformer en règlement intérieur.

Le premier projet public du W3C, daté du 3 juillet 2012, proposait une interface concise. requestFullscreen() sur un élément demandait son affichage en plein écran. exitFullscreen() sur le document y mettait fin. fullscreenElement indiquait l’élément actuellement projeté. Les deux méthodes renvoyaient alors void. Ce texte était un Working Draft : sa date renseigne sur la publication d’un projet, pas sur une recommandation achevée ni sur la première mise à disposition par un navigateur particulier.

Le problème dépassait la taille du rectangle. Un site savait déjà dessiner un énorme bloc en CSS. Le projet plaçait l’élément plein écran dans une pile propre au document et dans le calque supérieur du contexte de navigation, au plus près du spectateur dans l’ordre d’affichage. Il fallait définir ce qui se passe quand le contenu de la page franchit la frontière de la fenêtre ordinaire. Un div enthousiaste n’obtient pas le titre de propriété du moniteur en criant plus fort que ses voisins.

La demande pouvait échouer. Le projet vérifiait notamment que l’élément appartenait à un document, que le contexte pouvait utiliser le plein écran et que les états imbriqués ne se contredisaient pas. Il utilisait aussi une condition liée à l’autorisation d’ouvrir une fenêtre, et tenait compte des préférences de l’utilisateur, des risques de sécurité et des limites de la plateforme. La page présentait une demande ; le navigateur pouvait la refuser. La location de la scène ne valait pas transfert du bâtiment.

La sortie figurait déjà dans ce contrat. Si l’utilisateur demandait au navigateur d’arrêter une séance lancée par l’API, le projet prévoyait une sortie complète. Un message expliquant comment partir était également envisagé. L’événement fullscreenchange permettait à la page d’apprendre que l’état avait changé, même si son propre script n’avait pas tiré le rideau. Le lecteur vidéo peut alors remettre ses commandes en place. Il ne peut pas transformer la séance en bail perpétuel.

La chronologie comporte un virage administratif aux conséquences techniques. Dans sa note du 18 novembre 2014, le W3C écrit que le travail sur ce document est interrompu et invite à consulter la spécification Fullscreen de WHATWG. Le projet de 2012 n’est jamais devenu, par cette opération, une recommandation W3C. L’API n’a pas non plus disparu : c’est l’adresse du travail normatif qui a changé. Les spectateurs avaient toujours besoin d’un écran et d’une porte.

Le standard vivant de WHATWG décrit un contrat actuel plus détaillé. requestFullscreen() et exitFullscreen() renvoient des promesses. En règle générale, la demande nécessite une activation transitoire de l’utilisateur, comme une interaction récente ; le texte prévoit aussi un cas précis de changement d’orientation provoqué par l’utilisateur. L’activation est consommée lorsque la demande passe. Cliquer pour agrandir une vidéo et voir une page s’emparer de l’écran au chargement ne sont pas deux invitations équivalentes.

Le modèle actuel conserve le calque supérieur. L’élément plein écran du document est le plus haut élément de ce calque dont l’indicateur plein écran est activé. :fullscreen aide à le présenter ; fullscreenchange et fullscreenerror permettent de traiter le changement ou le refus. Ces mécanismes appartiennent au texte actuel. Les promesses d’aujourd’hui ne doivent pas être attribuées au projet de 2012, dont les signatures et les conditions d’entrée étaient formulées autrement. Une histoire de standards a des versions, pas une seule affiche jaunie.

Les contenus intégrés rendent la question du pouvoir très concrète. Si une vidéo d’un tiers se trouve dans une iframe, peut-elle prendre seule tout l’écran ? La politique de permissions du standard actuel traite fullscreen comme une fonctionnalité contrôlée, autorisée par défaut pour 'self'. Le contenu imbriqué requiert une permission explicite, via allowfullscreen, allow ou un en-tête de politique adapté. Une salle peut inviter une troupe étrangère. Elle garde le droit de décider qui occupe la scène.

Reste la petite lumière au-dessus de la porte. Le standard actuel demande aux navigateurs de rendre le plein écran perceptible, de proposer une sortie qui fonctionne toujours et d’en avertir l’utilisateur. Il nomme le danger : une page en plein écran peut imiter le navigateur, voire le système d’exploitation. Le navigateur peut mettre fin à une séance quand il le juge nécessaire. Ce pouvoir n’est pas une exception gênante à l’expérience immersive ; c’est ce qui permet de lui faire confiance.

L’API a ouvert le web au cinéma, aux jeux et aux présentations sans obliger chaque site à inventer ses propres règles d’évacuation. Le rideau peut cacher l’encadrement du navigateur. Il ne peut pas effacer l’autorité de celui qui garde la porte, ni les jambes de la personne qui choisit de partir.