The <geolocation> element lands in Chrome 144

I wired up a scratch page with the new <geolocation> element the morning I read the writeup, and the surprise is how small the markup gets. What used to be a navigator.geolocation.getCurrentPosition(...) dance is now a handful of attributes on a single tag.

Per the Piccalilli writeup, <geolocation> ships in Chrome 144+. The element began life as a general-purpose <permission> element and was narrowed down to geolocation specifically. The article's headline claim is that it is better than the older Geolocation JavaScript API in every way except browser support, and after wiring it up that framing lines up with what the attributes and events actually let you do.

The smallest useful markup

Per the source, the element takes three main HTML attributes:

• accuracymode, which accepts approximate (the default, equivalent to enableHighAccuracy: false) or precise (equivalent to enableHighAccuracy: true).
• autolocate, a boolean that requests a location automatically when permission was previously granted.
• watch, a boolean that turns a one-shot read into a continuous stream, the same distinction as getCurrentPosition vs watchPosition on the older API.

There is also an onlocation attribute for wiring an inline handler to the update event. The source does not hand you a full opinionated skeleton beyond those, so I am not going to invent one. Read the surface plainly: three declarative knobs and a place to attach a listener.

Reading position from JavaScript

You still need JavaScript to get the coordinates out. Per the source, feature-detect with if ("HTMLGeolocationElement" in window). On the element itself, the writeup names these properties: isValid, invalidReason, initialPermissionStatus, permissionStatus, position and error. Position data mirrors the shape you already know from the older API: position.coords (with latitude, longitude, altitude, accuracy, altitudeAccuracy, heading and speed) and position.timestamp.

Four events fire on the element per the source: validationstatuschange, promptaction, promptdismiss and location. The last one is the one you spend most of the day with. The two prompt* events are the pieces the older API never gave you: a hook for when the browser's permission prompt is shown or dismissed, without you having to manage the modal yourself.

A styleable granted state

This is the part that made me sit up. Per the source, there is a :granted CSS pseudo-class that reflects the granted permission state on the element. The article uses it as :not(:granted) — style the fallback UI while permission is missing, then let the granted state take over. That is a real declarative expression of a state that used to live in JavaScript, and it means the "waiting for the user" and "we have coordinates" branches of your UI can be written in CSS alone. Recovering from a prior denial is also called out in the writeup: the element supports user-controlled re-prompting even after a previous deny, which is a specific rough edge of the old API.

Progressive enhancement in one tag

The recommended pattern in the source is neat. Put a fallback button inside the <geolocation> tags. On supporting browsers the element renders itself and hides the child; on non-supporting browsers the child renders as if the parent were not there. Wire that button to navigator.geolocation.watchPosition() or navigator.geolocation.getCurrentPosition() in the usual way. One markup path, one JS path, and no runtime branching in your component tree.

Where it runs, and where it does not

Read the support line honestly. Per the source, this is Chrome 144+, one engine. The writeup makes no Baseline claim, and does not report Firefox or Safari status, and neither will I. So the deployment story is: keep the fallback in place, add the <geolocation> element as the enhancement, feature-detect at runtime with HTMLGeolocationElement in window before you rely on any of the new events, and leave the old navigator.geolocation call site alone until the other engines land it.

What I'm watching next

Two things. First, whether :granted picks up matching implementations in the other engines. A state-driven pseudo-class is only as useful as its cross-engine reach. Second, whether the <permission> origin of this element grows sibling elements for the other permission-gated APIs, or whether <geolocation> stays a single-purpose tag. For now I am adding it as a progressive enhancement on one page that already talks to the older API, and letting the fallback carry everyone else.