VioletPixel

🧭 Ideas for Safe Area Improvements on the Web

Jen Simmons on the WebKit blog:

You might have noticed the outer display of iPhone Duo is wider and shorter than other iPhone displays. To give content more vertical space, iOS moves controls to the side.

In Safari 27.1, web content does not currently extend to fill the space behind these controls. Just like on other platforms, Safari looks at the web page and extends its background color to fill the space.

We would like to give web designers and developers the ability to design and use that space in more creative ways. Perhaps you want to extend your header background across the full width of the display, for example. It might seem like there’s just one obvious way to make this possible, but really there are many possibilities.

We could use the HTML viewport meta tag with viewport-fit="cover" to extend the webpage into that space, hoping developers also use the appropriate environment variables to scoot important content away from system controls. But as we research how today’s sites are built, we see a lot of projects that fail to inset all four edges correctly. We are investigating if there’s a better way to accomplish the same result — something more foolproof and perhaps easier for you to use. If you have ideas, we’d love to hear them. And stay tuned.

It doesn't surprise me that people aren't implementing safe area insets correctly. I've used them (or attempted to use them) on several sites I've built over the years, and they're often more trouble than they're worth. I find them unintuitive and inscrutable until I've re-read the documentation again in full, and even then it's a struggle. I find it difficult to reason about how the env() and min()/max() values interact with margin and padding when you're building or tweaking something, and it's even worse when you go back to work on old CSS after your safe area insets mental model was purged from your brain long ago.

Take Apple's safe area insets sample code for example:

@supports(padding: max(0px)) {
  .post {
    padding-left: max(12px, env(safe-area-inset-left));
    padding-right: max(12px, env(safe-area-inset-right));
  }
}

Even with this minimal example you have to do a lot of mental gymnastics to figure out what those padding values will end up being for a given device in a given orientation.

Taking it one step further, truly effective and future-proof use of safe area insets requires you to understand not just the specific technical implementation for a given website/browser/device combo, but the spirit and intention behind the system itself. You need to think not just about how safe area insets are going to get your site working with today's devices, but also future devices and browsers that may have safe areas and display sizes that don't exist today.

Some web designers and developers are going to have the motivation, resources, and time, to do that. Many—probably most—will not.

Even for the folks who do go to all that trouble, testing and validating safe area behavior is painful and difficult. You either need to own several expensive devices or own a Mac and download, install, and run a bunch of simulators. That's way too many hoops to jump through.

Now, all of that said, I think safe area inserts are useful and should stick around. They're a complex solution for certain complex and advanced problems and use cases.

The problem isn't that safe area insets are complex or hard to use, the problem is that safe area insets shouldn't be our only option. There should be simpler, intermediate options between "do nothing and use the default behavior" and "jump into the deep end with safe area insets."

It should also be far easier to test, validate, and have confidence your website will work as expected on not just today's devices, but tomorrow's as well.

I've got some ideas!

The simplest option: set a color

Let's start by adding the ability to specify the color used outside the safe area. This could be a new option on the viewport meta tag called outside-safe-area-color:

<meta name="viewport" content="initial-scale=1, outside-safe-area-color=#80f">

Easy, simple, clear, and useful. The use cases are limited, but this will come in handy for a lot of situations.

A balanced option that's best for most sites: extend backgrounds

Most people want the ability to tell Safari, "extend the backgrounds of elements that touch the edge of the safe area to the edge of the display... no, not that one, and this one should be different when extended... yeah, like that," but without adding a lot of inscrutable complexity to their CSS.

Let's give them that ability.

We'll start with a new viewport-fit option that tells the browser to extend the background of any elements touching the edge of the safe area to the edge of the display called extend-backgrounds:

<meta name="viewport" content="initial-scale=1, viewport-fit=extend-backgrounds">

The extend-backgrounds option would tell the browser to keep the content of elements touching the edge of the safe area where it is—inside the safe area—while extending the background of those elements to the edge of the display. The layout of the content and the overall page inside the safe area would remain intact.

Beyond the literal background of an element, an element's extended background would include borders, outlines, shadows, filters, and so on.

With just that one option we've already provided a viable path for a ton of sites, but we can accommodate a lot more by adding an extend-behavior option:

<meta name="viewport" content="initial-scale=1, viewport-fit=extend-backgrounds, extend-behavior=horizontal">

In the example above backgrounds are only being extended horizontally, not vertically.

Here are all the possible values for the extend-behavior option:

Those last four options can be mixed and matched with delimiters to allow for background extension in only specific directions, like so:

<meta name="viewport" content="initial-scale=1, viewport-fit=extend-backgrounds, extend-behavior=top;right">

We can also add additional granularity by adding some new CSS properties:

Some examples:

#element-with-fixed-background-image {
  extend-behavior: none;
}

#element-that-should-only-extend-to-the-right-and-bottom {
  extend-behavior: right bottom;
}

#element-with-custom-extended-background {
  extended-background-color: rebeccapurple;
  extended-background-border: none;
}

When laying out content inside an element or determining the size of an element (e.g., with JavaScript), the non-extended dimensions of the element would be used. In other words, the extended background of an element has no effect on the layout of its content or surrounding elements. This will minimize breakage across a wide range of sites and use cases.

Extended backgrounds will work best for elements that use solid colors or repeating patterns for their backgrounds.

Elements with gradient backgrounds will be a mixed bag depending on how the gradient is being used and the overall design of the site. When background gradients don't work well it's likely adding an appropriate extended-background-gradient: declaration will do the trick.

Elements with single image backgrounds and certain kinds of borders and drop shadows will likely need the most attention when using extended backgrounds. It's likely some of these should be excluded with extend-background: none; while others can be adjusted with a different extender background appearance using various extended-background-*: properties.

Extended backgrounds won't work for every site, but they don't need to. For sites with more demanding requirements, viewport-fit=cover and safe area insets can be used instead.

Easy, fast, and practical testing and validation

To increase adoption and confidence around outside safe area colors, extended backgrounds, and safe area insets, people need a quick and easy way to see what these options are actually doing and confirm they're going to work for both today's devices and tomorrow's. And all of that should be possible regardless of the device any particular designer or developer has access to.

The solution is a web-based tool that shows how a given site will look on various Apple devices (e.g., iPhone 18, iPhone Duo, etc.) and other, theoretical devices that may or may not exist in the future. The tool doesn't need to replicate the visual fidelity of those devices, browsers, or operating systems (no need to get Liquid Glass working on the web in any browser), they just need to show how a website's content will or won't be occluded by things outside the safe area when different options are used.

For theoretical future devices, the tool would generate (within reasonable limits) random display sizes, random safe area sizes, and random occlusions outside the safe area (e.g., notches, Dynamic Islands, toolbar buttons, etc.) every time it's used. Those random factors would prevent people from falling into the trap of making their site work for one specific device without realizing it breaks on others.

Everything in a nutshell

With these proposed additions, people making websites would be able to choose the solution with the right effort/level of control ratio that's suitable for their project:

Those options, combined with an easy-to-use web-based tool that anyone can use to test and validate the solution they working with, will be leaps and bounds easier and more approachable than what we have today. In most cases, people would only need to spend a few minutes to make their site look great on every device, not hours, days, or weeks.

These proposals need a lot of refinement and feedback, and I'm sure there are a lot of great ideas I haven't thought of. Still, I hope these ideas can act as a jumping-off point that leads to a better situation for everyone. I'd love to live in a world where most of the websites I visit—from the largest corporate sites to indie blogs—look their best no matter where and how they're viewed.