Résumé

  • Le projet DOM4 du W3C de décembre 2012 décrivait déjà les observateurs de mutations et leurs files de relevés. La Recommandation de novembre 2015 présentait explicitement ces observateurs comme successeurs des Mutation Events.
  • Le DOM actuel permet de suivre des ajouts ou retraits d’enfants, des attributs et du texte, éventuellement dans tout un sous-arbre. Le navigateur prépare les relevés et avertit l’observateur dans une microtâche ; l’auteur décide comment mettre son interface à jour.

Imaginons un calendrier qui affiche des cartes de réunion. Une opération en ajoute une, une autre change un intitulé, une troisième retire la réunion passée. Le module qui entretient l’index aimerait recevoir le bilan après cette petite valse. S’il intervient au milieu de chaque geste, il risque de compter les chaises pendant qu’on les porte encore. Un courrier regroupé lui donne un moment plus sensé pour travailler.

Le projet DOM4 du W3C du 6 décembre 2012 définissait déjà les observateurs, leurs files de relevés et les opérations pour cesser l’observation ou prélever les avis en attente. Le navigateur n’avait pas besoin de comprendre ce qu’était une réunion. Il devait savoir quel nœud avait changé et quel observateur avait demandé la nouvelle. L’historique officiel de DOM4 situe ce projet sur la route qui conduisit à une Recommandation.

La Recommandation DOM4 du 19 novembre 2015 annonçait le remplacement des Mutation Events par les Mutation Observers. Au lieu de traiter chaque retouche de l’arbre comme un événement lancé au point même de la modification, le mécanisme place des objets MutationRecord dans les files des observateurs intéressés. Une microtâche composée déclenche ensuite leur notification. Plusieurs retouches peuvent ainsi arriver dans le même paquet à la fonction de rappel.

L’abonnement se règle finement. childList suit les enfants ajoutés ou supprimés, attributes les attributs, characterData les données textuelles. subtree étend la surveillance aux descendants ; un filtre peut limiter les attributs suivis. Certaines options conservent l’ancienne valeur d’un attribut ou d’un texte. Le calendrier peut donc écouter la liste qu’il gère au lieu de se faire raconter toutes les aventures de la page.

Un relevé porte un type et une cible. Selon le changement, il peut préciser les nœuds ajoutés ou retirés, les voisins, le nom d’un attribut et une ancienne valeur. Le module du calendrier lit le paquet et décide quelles cartes réclament une mise à jour. Le navigateur fournit l’enveloppe et l’heure de distribution ; le code de la page donne un sens au message. La sélection découle des options d’observation choisies par l’auteur.

Le DOM Living Standard de WHATWG définit aujourd’hui la livraison : une microtâche est mise en file pour avertir les observateurs, puis leurs relevés leur sont remis. takeRecords() renvoie et vide les relevés en attente quand le code veut les récupérer directement. disconnect() arrête l’observation et nettoie la file. Une bibliothèque peut ainsi commencer sa tournée avec le calendrier et la terminer quand celui-ci disparaît.

L’historique du W3C mentionne le retrait de son instantané DOM4 en 2020 ; les règles actuelles vivent dans le DOM maintenu par WHATWG. Les archives de 2012 et 2015 montrent comment l’idée est entrée dans les textes. Le contrat qui dure tient en peu de choses : le navigateur rassemble les changements choisis, puis chaque auteur répare la partie de la page dont il a la charge. La boîte aux lettres distribue les nouvelles ; elle laisse aux habitants le soin de répondre.