Kilian Valkhof

Your page can’t change media features

Yesterday on Mastodon we had a short discussion about the (terribly named) overflow media feature. Because it has the same name as a CSS property it’s easy to think it has more power than it really does. Underlying that is the issue that your page can’t change the value of a media feature: media features say something about the medium: the device, browser or user preferences.

Media features #

When I’m talking about media features, I mean the bit between parenthesis in a media query, like (min-width: 600px). It checks if the available width in the browser is at least 600 pixels wide and if so, it applies the styles inside the media query. You then use this to make your page adapt to the available width: The medium determines and your code adapts.

This is easy enough to reason about when it’s clear you’re dealing with device characteristics: the screen dimensions are the screen dimensions and the only time the orientation changes is when the user rotates their device.

It gets a little more confusing when you move on to user preferences, like the prefers-color-scheme media feature. That checks if the user had set a preference for light or dark mode in their OS, and you can use it to adapt your page to the user’s preference.

Your site can have a dark mode or a light mode, but the user’s preference isn’t going to change if you don’t offer one or the other.

Enter “overflow” #

The “overflow” property in CSS lets you control how an element should handle overflowing content, by clipping it, hiding it, showing a scrollbar or just showing it outside of the element. It’s a CSS property, so you as the developer can change it.

The overflow media feature (or rather, the feature split out into both directions: overflow-block and overflow-inline) has the same name, and does something totally different.

Media features say something about the device, and the overflow media feature says something about how the device handles overflowing. It doesn’t say anything about if the page currently is overflowing, just how it would handle overflowing.

Overflow can be used to check how the “device”, or rather the medium in this case, handles overflowing content. On a screen, in most browsers, overflow is going to be “scroll”: If the content overflows, the device deals with that by letting you scroll. But when your medium is print overflow-block is going to evaluate to “paged”. Paper doesn’t scroll, it will continue the content on the next printed page instead.

So that’s essentially what overflow can do. It tells you if your page is being shown in a situation where, if there is overflowing content, it is scrolled, paged or clipped. This holds regardless of whether your page actually has overflowing content or not.

Why is this important? #

Media features are about the medium, not about the page. Keeping that in mind makes things easier to reason about. If you’re trying to use the overflow media feature to check if your page has overflowing content, you’re going to be disappointed. It’s not going to tell you that. It’s going to tell you how the medium would handle it if you did.

In the future, I’ll have lied #

An exciting upcoming API is the web preferences API. The web preferences API provides a way for developers to (for the user) set preferences for their site that can then override the user’s OS preferences.

This is a way for developers to offer (for example) a light mode/dark mode choice regardless of what they have set on an OS level. Currently to do this, you need to duplicate all your styling: once for inside the media query, and once for your custom implementation, behind a class for example. With the web preferences API your custom implementation will also trigger the media query. You’ll only need to write your styling once.

The web preferences API is still in development, but you can play around with it in Polypane, or other Chromiums with experimental features turned on.