Publié le 7 février 2025
En avril 2024, un post sur ce site a annoncé que l'API Popover était disponible en tant que référence. Cependant, nous nous sommes trompés, et le pop-up entre dans la référence à partir du 27 janvier 2025. Cet article explique pourquoi nous nous sommes trompés et ce qui a changé depuis pour que ces erreurs soient moins susceptibles de se produire.
Qu'est-ce que l'API Popover ?
L'API Popover fournit une méthode intégrée pour créer différents types de popovers utilisés dans les applications Web. Auparavant, vous deviez utiliser JavaScript et veiller à les implémenter de manière accessible. L'API apporte tout cela au navigateur, et un popover simple peut être créé de manière déclarative en HTML.
<button popovertarget="my-popover">Open Popover</button>
<div id="my-popover" popover>
<p>I am a popover with more information. Hit <kbd>esc</kbd> or click away to close me.</p>
</div>
Pourquoi n'était-ce pas la référence en avril 2024 ?
Lorsque Firefox a publié son implémentation des popovers en avril 2024, nous n'avions pas encore découvert qu'il existait un problème important sur iOS et iPadOS. Dans ces navigateurs mobiles, cliquer en dehors du popover ne le fermait pas, une fonctionnalité appelée fermeture légère. Il s'agit d'un problème qui empêcherait la plupart des développeurs d'utiliser le popover. Par conséquent, il n'aurait pas dû être inclus comme référence en avril, et il a fallu attendre que le bug soit corrigé dans Safari 18.3.
Pourquoi avons-nous fait une erreur ?
La référence s'appuie sur la tâche web-features pour calculer quand les éléments géographiques sont dans ou en dehors de la référence. Si vous examinez un fichier de fonctionnalités individuel de ce projet, comme le fichier pour le popover, vous verrez les fonctionnalités individuelles des données de compatibilité du navigateur Mozilla listées. Une fonctionnalité Web contient généralement un certain nombre de ces inclusions. En effet, une fonctionnalité sur le Web n'est pas une simple propriété ou méthode. Elle nécessite un certain nombre de composants pour fonctionner. Une fonctionnalité n'est pas une spécification complète. Les spécifications CSS, par exemple, incluent souvent des sous-fonctionnalités qui n'ont jamais été implémentées ou qui ne sont utilisées que dans un contexte spécifique. Le travail sur les fonctionnalités Web utilise une combinaison de données de disponibilité existantes et d'informations fournies par l'utilisateur pour déterminer ce qui constitue une fonctionnalité de plate-forme Web et, surtout, si une implémentation partielle est suffisamment grave pour ne pas être incluse dans la référence.
En février, le travail sur les fonctionnalités Web était loin d'être terminé. Par conséquent, pour montrer comment Baseline fonctionnerait, nous essayions de déterminer les principales fonctionnalités qui feraient partie de Baseline 2024 sans toutes les données dont nous avions besoin pour ce faire. Sur le papier, ou plutôt dans les données de compatibilité du navigateur qui n'ont pas été mises à jour avant septembre, date à laquelle le problème a été détecté, le popover semblait être inclus. Toutefois, en raison du bug suffisamment grave sur iOS pour empêcher l'utilisation du popover, il n'était pas prêt.
Il manquait également une infrastructure de test pour les mobiles. Le projet Tests de la plate-forme Web nous permet de vérifier que les fonctionnalités de la plate-forme Web fonctionnent dans tous les navigateurs. Si ce problème de fermeture de la lumière s'était produit dans un navigateur pour ordinateur, nous aurions constaté que les tests échouaient, ce qui n'était pas le cas pour les mobiles.
Comment éviter cela à l'avenir ?
Nous sommes déjà beaucoup mieux lotis avec les données. Les données sur les éléments géographiques Web sont presque complètes. Nous pouvons donc avoir un niveau de confiance plus élevé pour toutes les fonctionnalités que nous déclarons comme référence.
Dans ce cas particulier, une partie du problème consistait à identifier un problème qui ne se produit que sur mobile, sous iOS. Plusieurs éléments devraient faciliter l'identification des problèmes d'interopérabilité sur mobile à l'avenir. Nous travaillons actuellement à améliorer les tests mobiles dans les tests de la plate-forme Web. Nous devrions ainsi pouvoir mieux identifier les problèmes d'un navigateur mobile, par rapport à ceux d'un ordinateur. Nous prévoyons également de les afficher dans le tableau de bord webstatus.dev cette année. Si un problème de ce type se produit à l'avenir, nous devrions recevoir des indications plus rapides, si possible avant d'inclure la fonctionnalité dans Baseline.
Nous savions toujours que cartographier l'ensemble de la plate-forme Web en tant qu'ensemble de fonctionnalités ne serait pas facile. Toutefois, les discussions que nous avons sur les implémentations partielles, les bugs et ce qui constitue réellement une fonctionnalité sont extrêmement utiles. Cela nous aide à identifier ce qui compte vraiment pour vous, ce qui nous permet d'obtenir de meilleurs signaux à utiliser lors de la planification d'efforts tels que Interop 2025.