🧠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:
auto - (default) extend backgrounds to every edge of the displayhorizontal - only extend backgrounds to the horizontal edges of the displayvertical - only extend backgrounds to the vertical edges of the displaytop - only extend backgrounds to the top of the displayright - only extend backgrounds to the right side of the displaybottom - only extend backgrounds to the bottom of the displayleft - only extend backgrounds to the left side of the display
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:
extend-behavior: - Specify or override the extended background behavior for matching elements; possible values include all of the extend-behavior options outlined above, plus:
none - disable extended backgrounds
extended-background: - Specify a different background to use when the background is extended
- You could also use
extended-background-color:, extended-background-image:, and so on.
extended-background-border: - Specify a different border to use when the background is extendedextended-background-outline: - Specify a different outline to use when the background is extendedextended-background-drop-shadow: - Specify a different drop shadow to use when the background is extendedextended-background-filter: Specify a different filter to use when the background is extended- And so on for all aspects of an element that extended backgrounds would extend
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:
- Zero effort, no control: do nothing to get the default behavior; the browser selects what it thinks is the most appropriate color to use for the space outside the safe area
- Very easy, low control: add a viewport meta tag with
outside-safe-area-color to specify which color is used outside the safe area
- Balanced effort and control: add a viewport meta tag with
viewport-fit=extend-backgrounds and, optionally, set extend-behavior or add extended-backgrounds-* CSS as needed
- Difficult, high control: add a viewport meta tag with
viewport-fit=cover and use safe area insets to do exactly what you want
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.
🥵 French Fridges Forced to 50°C
The Guardian:
Hackers have forced the temperature of many French supermarket fridges up to 50C overnight, in an “unprecedented” cyber-attack affecting several hundred stores across the country, with fires and food losses reported.
That's 122° F.
The affected units “were running outdated firmware”, Danfoss said, adding that it had “long advised customers to keep supported systems updated with the latest firmware and to migrate legacy systems to current-generation solutions”.
Most people—including large and small groups of people, like businesses—are really bad at keeping their firmware up to date. That goes double for things that exited for a long time without firmware, like appliances. It goes triple for things that people may not realize are even connected to the Internet. A lot of people just don't realize things like toasters, ovens, and fridges are online or that they need to be updated, especially when those things are working fine.
The French president, Emmanuel Macron, a strong supporter of Ukraine in its fight against the Russian invasion, last month ordered measures to protect France’s critical infrastructure from Russian “hybrid attacks”.
If we're lucky, the next several months are going to be really rough. As the capabilities of LLMs increase, so does their danger. Every day more potential bad actors realize how easy it is to take advantage of old, unpatched systems and, in some cases, how easy it is to find latent vulnerabilities in up to date code. Every day, more LLM agents are being turned loose to accomplish their goals however they see fit, and sometimes that means they break containment or cause unintended side effects. It wouldn't surprise me if the attack described in this story was carried out intentionally by Russia, but it also wouldn't surprise me if this happened as an unintended side effect of LLM agents trying to accomplish something entirely unrelated.
Again, that's if we're lucky. If we're unlucky, we won't be dealing with more and more of this kind of thing for months, we'll be dealing with it for years.
But it's not all doom and gloom. The people trying to keep everything online and secure can fight fire with fire. The same LLMs causing these problems can be used to find and fix more issues before they're exploited. LLMs can also help teams respond quickly when something goes off the rails.
I don't like LLMs, but I can't deny their utility in some areas.
It's an interesting time to be alive.