Résumé

  • Le 11 février 2020, le W3C publiait le premier projet public de Resize Observer : une API qui observe les changements de taille d’un élément et remet les mesures à une fonction de rappel.
  • Le projet d’éditeur du CSSWG distingue les boîtes de contenu, de bordure et de contenu en pixels de l’appareil. Son modèle de traitement limite les notifications répétées pendant le rendu et signale celles qui restent à livrer.

Une carte de tableau de bord peut changer de largeur sans que la fenêtre bouge. Il suffit qu’un menu latéral s’ouvre ou qu’une colonne de grille cède de la place à sa voisine. Le graphique dans la carte doit peut-être réduire le nombre de repères sur son axe. Le système de grille ne connaît pas la typographie du graphique ; le graphique ne décide pas de la largeur que la page lui accorde. Il leur faut une conversation plus précise que « la fenêtre a changé ».

Le premier projet public du W3C, daté du 11 février 2020, décrit une interface pour observer la taille d’éléments. On crée un ResizeObserver, on lui confie un élément avec observe(), puis on reçoit des entrées lorsque la taille observée change. unobserve() retire une cible ; disconnect() clôt les observations de l’instance. L’historique officiel du W3C confirme la date et le statut de premier projet public. La mesure se rapproche de la pièce du puzzle qui doit vraiment s’adapter.

Prenons un graphique qui tient dans une carte. Quand la barre latérale avance, le navigateur recalcule la mise en page. L’observateur peut alors livrer au graphique la nouvelle taille de sa boîte. Son auteur choisit de raccourcir les étiquettes, de déplacer une légende ou de redessiner la courbe. L’API transmet une donnée commune ; elle laisse la décision de présentation à celui qui connaît le contenu.

Encore faut-il choisir ce qu’on mesure. Le projet d’éditeur Resize Observer Module Level 1 du CSSWG propose content-box, border-box et device-pixel-content-box. La première mesure l’espace du contenu, la deuxième comprend la zone de bordure, la troisième exprime le contenu en pixels de l’appareil avant les transformations CSS. Un texte peut se soucier de sa largeur utile ; un cadre de sa taille extérieure ; un dessin sur canvas de la résolution réellement disponible. Trois règles graduées dans la même boîte à outils.

Le choix de boîte passé à l’observateur détermine quel changement déclenche une livraison. L’entrée reçue donne aussi des informations de taille. Cette séparation entre déclencheur et données évite de lire le rappel comme un ordre de tout recalculer. Un composant supprimé devrait d’ailleurs être retiré de l’observation : inutile de convoquer chaque soir le géomètre devant une maison démolie.

Le rappel peut provoquer un problème plus drôle à raconter qu’à déboguer. Il découvre une carte trop étroite, l’élargit, reçoit une nouvelle mesure, la rétrécit, puis recommence. Le navigateur ne peut pas passer le rendu entier à regarder ce duo se disputer. Le projet du CSSWG décrit une livraison liée au cycle de rendu et ordonnée selon la profondeur des éléments. Des changements laissés en attente peuvent produire un signal d’erreur de boucle et être livrés dans une image suivante. L’auteur doit concevoir une réaction qui se stabilise : adapter le graphique à la place reçue, plutôt que faire osciller la place elle-même.

Les trois originaux établissent le statut documentaire et le mécanisme. Le texte du CSSWG est un projet d’éditeur daté du 22 novembre 2022 ; l’historique du W3C garde l’étape de 2020. L’intérêt historique tient à la précision du regard. Le navigateur mesure désormais l’espace effectivement attribué à un élément, et le composant décide ce que cet espace lui permet de faire.