Le nouvel élément HTML Geolocation

Si vous avez déjà utilisé navigator.geolocation.getCurrentPosition(), vous connaissez la routine : écrire le callback, gérer l’erreur, administrer l’état de permission, et espérer que le navigateur n’avale pas silencieusement l’invite parce que l’utilisateur l’a rejetée une fois de trop. Le nouvel élément HTML <geolocation> adopte une approche entièrement différente : la géolocalisation déclarative en HTML, gérée par le navigateur lui-même.

Voici ce que c’est, comment ça fonctionne, et ce que vous devez savoir avant de l’utiliser.

Qu’est-ce que l’élément HTML <geolocation> ?

L’élément HTML <geolocation> est un bouton expérimental contrôlé par le navigateur qui permet aux utilisateurs de partager leur localisation directement depuis la page. Au lieu que votre JavaScript déclenche une invite de permission, l’utilisateur active le contrôle lui-même. Le navigateur gère le flux de permission, et vous écoutez le résultat.

Il a été livré dans Chrome 144. Début 2026, cela reste une fonctionnalité portée par Chromium et n’a pas encore été implémentée dans d’autres moteurs. Considérez-la comme quelque chose à expérimenter, et non à déployer universellement sans solution de repli. Vous pouvez suivre l’état actuel de l’implémentation sur https://caniuse.com/mdn-html_elements_geolocation.

Le problème avec l’API Geolocation

L’API navigator.geolocation est impérative. Votre script appelle getCurrentPosition(), le navigateur décide s’il faut afficher une invite, et si l’utilisateur a rejeté cette invite plusieurs fois, Chrome peut silencieusement la bloquer pendant une certaine période. Pas d’erreur, pas de retour — juste le silence.

Le manque de contexte aggrave la situation. Une invite qui apparaît sans explication est rejetée par réflexe. Ce rejet peut devenir persistant, et il n’y a pas de moyen évident pour les utilisateurs de l’annuler.

Comment la géolocalisation déclarative en HTML résout ce problème

L’élément <geolocation> inverse le modèle. L’utilisateur clique sur le bouton. Ce clic est le signal de permission. Le navigateur sait que la demande provient d’une action délibérée de l’utilisateur, ce qui permet d’éviter les scénarios de blocage silencieux et offre aux utilisateurs un chemin de récupération plus clair s’ils ont précédemment refusé l’accès.

L’interface HTMLGeolocationElement expose le résultat directement sur l’élément :

<geolocation onlocation="handleLocation(event)"></geolocation>

function handleLocation(event) {
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log(latitude, longitude);
  } else if (event.target.error) {
    console.error(event.target.error.message);
  }
}

L’élément expose les propriétés position et error, et vous écoutez des événements tels que location lorsque le navigateur retourne un résultat.

Attributs clés

• autolocate — Si la permission a été accordée précédemment, déclenche l’événement location au chargement de la page sans nécessiter de clic. Ne fait rien si la permission n’a pas encore été accordée.
• watch — Reflète watchPosition(), se déclenchant continuellement au fur et à mesure que l’appareil se déplace.
• accuracymode — Accepte "precise" ou "approximate". Le mode précis correspond à enableHighAccuracy: true et change l’icône du bouton en réticule. Notez que sur les ordinateurs de bureau, la différence est souvent négligeable — testez sur un appareil mobile en extérieur pour voir une variation réelle.

Une particularité à connaître : vous ne pouvez utiliser que jusqu’à trois éléments <geolocation> par page. Si vous dépassez ce nombre, tous cessent de fonctionner.

L’élément repose toujours sur le même modèle de sécurité sous-jacent que l’API Geolocation, qui nécessite un contexte sécurisé (HTTPS) et une permission explicite de l’utilisateur.

API Geolocation vs élément HTML Geolocation : lequel utiliser ?

Pour l’instant, les deux. L’élément HTML <geolocation> ne remplace pas navigator.geolocation — il l’encapsule. Utilisez l’élément là où il est pris en charge, et prévoyez une solution de repli élégante :

<geolocation onlocation="updateMap()">
  <!-- Rendu uniquement dans les navigateurs qui ne prennent pas en charge <geolocation> -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Utiliser ma localisation
  </button>
</geolocation>

Les navigateurs qui prennent en charge l’élément suppriment le contenu enfant. Les navigateurs qui ne le prennent pas en charge affichent le bouton de repli. Si vous souhaitez une approche plus automatisée, il existe un polyfill sur npm qui remplace par un élément personnalisé basé sur l’API standard.

La détection de fonctionnalité est simple :

if ('HTMLGeolocationElement' in window) {
  // élément pris en charge
} else {
  // utiliser navigator.geolocation
}

Le style a des limites strictes

L’élément ressemble à un bouton mais ne se comporte pas comme tel du point de vue CSS. Le navigateur impose des contraintes pour empêcher les modèles trompeurs : l’opacity est verrouillée à 1, le contraste entre le texte et l’arrière-plan doit être d’au moins 3:1, et les transformations déformantes sont bloquées. Si le contraste ou la taille de police tombe en dessous du seuil minimum, le bouton ne se désactive pas visuellement — il cesse simplement de fonctionner. Vous pouvez utiliser la pseudo-classe :granted pour styliser le bouton après l’octroi de la permission.

Vers où cela se dirige

L’élément <geolocation> est le premier d’une série prévue d’éléments spécifiques aux capacités. Un élément <usermedia> pour l’accès à la caméra et au microphone est déjà en essai d’origine. Le modèle — déclaratif, initié par l’utilisateur, médié par le navigateur — est clairement la direction que prend la plateforme.

Conclusion

L’élément <geolocation> représente un changement significatif dans la façon dont les navigateurs gèrent les permissions sensibles. En déplaçant le déclencheur du script vers l’action de l’utilisateur, il contourne de nombreux pièges de blocage silencieux de l’API impérative et donne aux utilisateurs un contrôle plus clair sur quand et s’ils partagent leur localisation. La prise en charge des navigateurs est encore limitée, mais le modèle de repli est propre et la surface de l’API est minimale. Commencez à expérimenter avec l’amélioration progressive dès aujourd’hui — l’expérience utilisateur des permissions est véritablement meilleure pour les utilisateurs, et le modèle déclaratif est la direction que prend la plateforme web.

FAQ

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.