Les info-bulles semblent être le plus petit problème d’interface utilisateur que vous puissiez rencontrer. Ils sont minuscules et généralement cachés. Lorsque quelqu'un demande comment en créer un, la réponse traditionnelle revient presque toujours en utilisant une bibliothèque JavaScript. Et pendant longtemps, ce fut un conseil judicieux. Je l'ai suivi aussi. En apparence, une info-bulle est simple. Survolez ou concentrez-vous sur un élément, affichez une petite boîte avec du texte, puis masquez-la lorsque l'utilisateur s'éloigne. Mais une fois que vous en envoyez un à de vrais utilisateurs, les limites commencent à apparaître. Utilisateurs du clavier Tabulez sur le déclencheur, mais ne voyez jamais l'info-bulle. Les lecteurs d’écran l’annoncent deux fois, voire pas du tout. L'info-bulle scintille lorsque vous déplacez la souris trop rapidement. Il chevauche le contenu sur des écrans plus petits. Appuyer sur Echap ne le ferme pas. La concentration se perd. Au fil du temps, mon code d’info-bulle est devenu quelque chose que je ne voulais plus vraiment posséder. Les auditeurs de l’événement se sont entassés. Le survol et la mise au point devaient être traités séparément. Les clics extérieurs nécessitaient des cas particuliers. Les attributs ARIA devaient être synchronisés manuellement. Chaque petite correction ajoutait une autre couche de logique. Les bibliothèques ont aidé, mais elles ressemblaient aussi davantage à des boîtes noires autour desquelles je travaillais au lieu de comprendre pleinement ce qui se passait dans les coulisses. C'est ce qui m'a poussé à examiner la nouvelle API Popover. Je voulais voir ce qui se passerait si je reconstruisais une seule info-bulle en utilisant le modèle natif du navigateur sans l'aide d'une bibliothèque. Pour commencer, il convient de noter que, comme pour toute nouvelle fonctionnalité, certaines choses sont encore en cours de mise au point. Cela dit, il bénéficie actuellement d’une excellente prise en charge du navigateur, bien que plusieurs éléments de l’API globale soient en évolution. En attendant, cela vaut la peine de garder un œil sur Caniuse. L'info-bulle « ancienne » Avant l'API Popover, l'utilisation d'une bibliothèque d'info-bulles n'était pas un raccourci. C'était la valeur par défaut. Les navigateurs n’avaient pas de concept natif d’info-bulle fonctionnant avec la souris, le clavier et la technologie d’assistance. Si vous teniez à l’exactitude, votre seule option était d’utiliser une bibliothèque, et c’est exactement ce que j’ai fait. À un niveau élevé, le modèle était toujours le même : un élément déclencheur, un élément d'info-bulle masqué et du JavaScript pour coordonner les deux.
La bibliothèque gérait le câblage qui permettait à l'élément de s'afficher au survol ou au focus, de se masquer en cas de flou ou de congé de la souris, et de repositionner/redimensionner lors du défilement.
Au fil du temps, l’info-bulle pourrait devenir fragile. De petits changements comportaient des risques. Des correctifs mineurs ont provoqué des régressions. Pire encore, l’ajout de nouvelles info-bulles héritait de la même complexité. Les choses fonctionnaient techniquement, mais ne semblaient jamais réglées ou complètes. C’était l’état des choses lorsque j’ai décidé de reconstruire l’info-bulle à l’aide de l’API Popover native du navigateur. Le moment où j'ai essayé l'API Popover Je n'ai pas opté pour l'API Popover parce que je voulais expérimenter quelque chose de nouveau. J'ai changé parce que j'en avais assez de maintenir un comportement d'info-bulle que je pensais que le navigateur aurait déjà dû comprendre. J'étais sceptique au début. La plupart des nouvelles API Web promettent la simplicité, mais nécessitent toujours de la colle, une gestion des cas extrêmes ou une logique de secours qui recrée discrètement la même complexité à laquelle vous essayiez d'échapper. J'ai donc essayé l'API Popover de la manière la plus réduite possible. Voici à quoi cela ressemblait :
1. Le clavier « fonctionne tout simplement » La prise en charge du clavier dépendait de l'alignement correct de plusieurs calques : la mise au point devait déclencher l'info-bulle, le flou devait la masquer, l'Esc devait être câblé manuellement et le timing comptait. Si vous manquiez un cas limite, l'info-bulle resterait ouverte trop longtemps ou disparaîtrait avant de pouvoir être lue. Avec l'attribut popover défini sur auto ou manuel, le navigateur reprend les bases : Tab et Shift+Tab se comportent normalement, Esc ferme l'info-bulle à chaque fois et aucun écouteur supplémentaire n'est requis.
Ce qui a disparu de ma base de code, ce sont les gestionnaires globaux de frappe, la logique de nettoyage spécifique à Esc et les vérifications d'état lors de la navigation au clavier. L’expérience clavier a cessé d’être quelque chose que je devais maintenir et elle est devenue une garantie du navigateur. 2. Prévisibilité du lecteur d'écran C'était leplus grande amélioration. Même avec un travail minutieux d'ARIA, le comportement variait, comme je l'ai souligné plus tôt. Chaque petit changement semblait risqué. Utiliser un popover avec un rôle approprié semble beaucoup plus stable et prévisible quant à ce qui va se passer :
Et voici une autre victoire : après le changement, Lighthouse a cessé de signaler des avertissements d'état ARIA incorrects pour l'interaction, en grande partie parce qu'il n'y a plus d'états ARIA personnalisés pour lesquels je me trompe accidentellement.
3. Gestion de la concentration La concentration était fragile. Avant, j'avais des règles telles que : laisser le déclencheur de mise au point afficher l'info-bulle, déplacer le focus dans l'info-bulle et ne pas fermer, flouter le déclencheur lorsqu'il est trop proche, fermer l'info-bulle et restaurer la mise au point manuellement. Cela a fonctionné jusqu’à ce que ce ne soit plus le cas. Avec l'API Popover, le navigateur applique un modèle plus simple dans lequel le focus peut se déplacer plus naturellement vers le popover. La fermeture du popover renvoie le focus sur le déclencheur, et il n'y a pas de pièges de focus invisibles ni de moments de focus perdus. Et je n’ai pas ajouté de code de restauration du focus ; Je l'ai supprimé.
Conclusion L'API Popover signifie que les info-bulles ne sont plus quelque chose que vous simulez. C'est quelque chose que le navigateur comprend. L'ouverture, la fermeture, le comportement du clavier, la gestion des évasions et une grande partie de l'accessibilité proviennent désormais de la plate-forme elle-même, et non de JavaScript ad hoc. Cela ne signifie pas que les bibliothèques d'info-bulles sont obsolètes, car elles ont toujours un sens pour les systèmes de conception complexes, les personnalisations lourdes ou les contraintes héritées, mais la valeur par défaut a changé. Pour la première fois, l’info-bulle la plus simple peut aussi être la plus correcte. Si vous êtes curieux, essayez cette expérience : remplacez simplement une seule info-bulle de votre produit par l'API Popover, ne réécrivez pas tout, ne migrez pas tout un système, choisissez-en une et voyez ce qui disparaît de votre code. Lorsque la plate-forme vous offre une meilleure primitive, le gain n'est pas seulement moins de lignes de JavaScript, mais aussi moins de choses dont vous devez vous soucier. Consultez le code source complet dans mon dépôt GitHub. Lectures complémentaires Pour une analyse plus approfondie des popovers et des API associées :
"Poppin' In", Geoff Graham "Clarifier la relation entre les popovers et les dialogues", Zell Liew "Qu'est-ce que popover=hint ?", Una Kravets « Commandes de l'invocateur », Daniel Schwarz "Création d'une notification de fermeture automatique avec un popover HTML", Preethi Explication de l'API Popover de l'interface utilisateur ouverte « Pop(over) les ballons », John Rhea «Positionnement d'ancre CSS», Juan Diego Rodríguez
MDN propose également une documentation technique complète pour l'API Popover.
