Résumé

  • Une discussion publique du W3C en 2013 chercha un moyen de diffuser un message à plusieurs contextes d'une même origine. En 2014, une demande ajouta les travailleurs; un échange public de 2015 suivit les premières expérimentations.
  • Dans le standard HTML actuel, le navigateur trouve les autres canaux admissibles portant le même nom et la même clé de stockage, sérialise le message et leur programme un événement. Chaque page décide de sa réaction.

Un lecteur se déconnecte dans un onglet, puis revient à une autre fenêtre où sa liste d'articles enregistrés paraît encore ouverte. Deux écrans, deux versions du même instant. La page pourrait attendre son prochain échange avec le serveur; elle pourrait aussi prévenir ses voisines tout de suite. Le navigateur était l'endroit naturel où tenir le standard téléphonique, puisque les onglets se trouvaient déjà dans ses murs.

Le dossier public ouvert au W3C en 2013 montre les auteurs du Web en train de chercher la bonne forme. Une proposition envisage un objet créé avec un nom de canal et une méthode postMessage(). Les autres objets de même origine et de même nom recevraient un événement. On y débat encore d'autres variantes : ce sont les brouillons d'un mécanisme, et l'idée maîtresse est qu'une fenêtre n'aurait plus besoin de connaître personnellement toutes les autres pour les prévenir.

La liste des destinataires s'élargit avec le ticket W3C de janvier 2014 consacré aux travailleurs. Sa mise à jour de juin consigne le changement dans le travail sur HTML. Un travailleur peut poursuivre une tâche en coulisses, alors que les fenêtres apparaissent et disparaissent. Lui permettre d'écouter le canal donne à la rédaction un réseau de bureaux plus cohérent : celui qui travaille derrière la porte entend aussi le message.

En janvier 2015, les archives publiques de WHATWG conservent un échange sur une implémentation destinée à Firefox Nightly et renvoient au texte HTML. L'index du projet HTML 5.1 du W3C, daté d'octobre 2015, recense l'interface BroadcastChannel et pointe vers sa définition chez WHATWG. Ces traces décrivent un chantier daté, assez concret pour que des implémenteurs y travaillent.

Le standard HTML actuel précise le trajet du billet. L'expéditeur choisit un canal nommé et poste une valeur; le navigateur la sérialise. Il cherche les autres canaux admissibles dont le nom et la clé de stockage correspondent, retire l'expéditeur de la liste, puis programme un événement message pour chacun. La page réceptrice doit être pleinement active; le travailleur doit être en état de recevoir. Le nom sur la porte ne suffit plus si les bureaux appartiennent à des compartiments de stockage différents.

Le texte du standard propose lui-même un exemple de déconnexion entre onglets. L'un annonce l'événement; l'autre rafraîchit son affichage. Le message est le coup de téléphone, tandis que chaque équipe effectue les gestes nécessaires sur son bureau. Même logique pour un changement de thème ou une file de tâches affichée à plusieurs endroits. Le navigateur distribue; l'application interprète.

Il reste une discipline de fin de journée. La norme invite à fermer les canaux inutiles : un objet encore muni d'un écouteur de messages peut rester en mémoire. Le standard téléphonique a simplifié une conversation locale, mais la rédaction doit raccrocher. Un billet bien distribué n'est utile que si chaque destinataire sait quoi en faire et quand cesser d'écouter.