The geolocation element is odd

posted on

Imagine the following scene: you're on a website, and there's a button. When you click the button, it shows some text, but the website's font size is really small. So, you change the default font size in your browser from 16 to 24 pixels. You go back to the website and click the button again, but it doesn't work now. That's not just very unfortunate, but it's also absolutely unexpected, confusing, and irritating.
With that picture in mind. Let's talk about some things that I find odd about the geolocation element.

First impression

When I first read about the geolocation element, my initial reaction was surprise. I was surprised to find a dedicated element for obtaining the user's location. I thought that could've also been a relatively simple web component instead.
On the Chrome for Developers blog, the authors explain that there are three main reasons for the existence of the element.

I wasn't 100% convinced, but the recovery and refresh features sold it to me. Still, I didn't think I would use this element much because I don't need to know the user's location very often. That's, of course, my problem.

When I learned everything I wanted to know, I wrote a simple introductory post about the element on my website. Five weeks later, I'm writing another post because I've learned some more surprising and strange things.

Styling constraints

You can style the geolocation element, but there are styling constraints to ensure user trust and prevent deceptive design patterns. I understand why these restrictions exist, but what confuses me is how they're implemented. They come in three flavours.

Enforced user agent styles

There are certain rules you can't overwrite because they are marked as !important in the user agent style sheet. For example, you can't change the box-sizing property.

permission, geolocation, install, usermedia {
  background-color:#efefef;
  border: solid 1px #767676;
  box-sizing: content-box !important;
  …
  word-spacing: normal;
  vertical-align: middle !important;
 }

That's not new. We already know this from other elements, like some form elements.

Enforced user agent bounds

Other rules are not important, but they have style bounds. For example, you can define a border-width, but the value must be between 0 and 0.6em.

Basically, anything that makes your button not look like a button is either prohibited or restricted. I understand that, and you also have enough properties at your disposal to change the design of your button to match your theme, but where it gets really strange is the third measure.

Element deactivation

I can live with enforced user agent styles and bounds, but if you define certain rules or do certain things, the element will be deactivated, and it won't work anymore.

The element just stops working without letting the user know when:

Demo

Try it yourself by increasing the font size using the range slider and then clicking the button. (You may have to press the button twice when you switch from a too large to a smaller font size. I have no idea why.)

Your browser doesn't support <geolocation>. Try Chrome 144+

Font size: 19px
Your location: press the button

Coming back to the intro of the post. If the font size of the geolocation is set to 2rem in the author style sheet and the user sets their browser's default font size to 25px, they won't be able to use the element just because they need a larger font size. The worst thing about this is that there is no visual feedback and no console error. You'll find an error message inside the Issues panel, but how many of you actually use the Issues panel, and how many of your users do?

I just can't understand how anyone could think that this was a good idea.

That's by far the worst thing of all the things I find strange about the element, but there's more.

JavaScript dependency

There aren't many HTML elements that fully rely on JavaScript to do anything meaningful (e.g., canvas). Geolocation is one of them. If I want to use the user's location, I have to attach an EventListener in JavaScript. I can't just process the data inside a form and pass it to a script via GET or POST. That's very unfortunate because if there's one thing I love about all these new features in HTML that replace custom JavaScript solutions (e.g., dialog with invoker commands, popover, details), it's that I don't need JavaScript at all.

PS: JavaScript dependency in HTML is actually an interesting topic. I'm working on a blog post about it.

Content restrictions

The element comes with an icon and a text label. You can hide the icon and select a locale for the text via the lang attribute, but that's it. You cannot change the text because the browser determines it. It's also not possible to show only an icon, as many websites do in their custom solutions.

geolocation::permission-icon {
  display: none;
}
<geolocation lang="de">
  <strong>Ihr Browser unterstützt das &lt;geolocation&gt; Element nicht.</strong>
</geolocation>
Ihr Browser unterstützt das <geolocation> Element nicht.

Dark Mode

At this point I'm unsure if this is a feature or just a bug, but the geolocation element doesn't support a dark color scheme.

<div style="color-scheme:dark">
  <geolocation></geolocation>
  <button>I'm a regular button</button>
</div>

Demo

Conclusion

Don't get me wrong, the element does the thing it's supposed to do well, but I can imagine that the styling and content restrictions will be a blocker for many people. Even if they can accept the limitations, they may not want to accept the possible issues that come with this horrible element deactivation feature. The least browsers should do is tell and show users that the button is deactivated and why. What I would find even better is to just define bounds for the font size instead of deactivating the element. For contrast, they could use the closest-matching combination for the text and background colors that has a ratio of at least 3:1.

I don't enjoy writing blog posts like this, but the element is in its current state not very useful. I've read the explainer and discussions on GitHub, I know that a lot of thoughts and work went into this, but the implementation feels a bit rushed.

Additional resources