Safari 18 — what web features are usable across browsers?
- Published at
- Updated at
- Reading time
- 4min
Safari 18 beta was released. And this will be a packed release. I love it!
Unfortunately, Apple doesn't share overall browser and baseline support in their release notes. So, I thought it would be nice to do "a state of the web check" and find out which of these new web features will be safe to use soon'ish.
This post includes fetched and up-to-date MDN compat data. I'll try to update the post when new features ship, but if you find outdated statements next to the compatibility tables, please let me know.
Let's go!
The Chrome folks have been pushing JS-based view transitions for a while now and the new Safari will join the party. What's the overall support?
111 | 111 | 111 | Nei | Nö | 18 | 18 | 22.0 | 111 |
Are they safe to use? Yes!
If you can live with older browsers and Firefox not showing fancy transitions, you can go all in because feature detection is a one-liner.
// Feature detect view transitions
if (document.startViewTransition) { /* ... */ }
After shipping container queries, the spec folks invented a new syntax to have style-based container queries based on custom properties.
@container style(--background: black) {
h2, h3, p {
color: white;
}
}
Fancy stuff. What's the support?
111 | 111 | 111 | Nei | Nö | 18 | 18 | 22.0 | 111 |
Are they safe to use? I don't think so.
After looking around, it seems that feature detection for @rules (@container
, @media
, etc) is still being worked on.
If you want to find out more about @rule feature detection:
Safari 18 supports the relative color syntax with currentColor
. That's exciting, but let's back up a second. What's the relative color syntax?
There's a post on this blog about relative color syntax in CSS. In short — the new color syntax allows you to destructure, alter and mix'n'match color values in CSS. You can use custom properties, switch color spaces, and build entire color palettes right in your CSS.
.something {
--color: red;
/* transform `red` to `hsl` and manipulate its lightness */
background: hsl(from var(--color) h s calc(l - 20%));
}
What's the support?
119 | 119 | 119 | 128 | 128 | 18 | Nei | 25.0 | 119 |
Is it safe to use? If you monitor your visitors' browsers and you're not dealing with too many outdated browsers, yes.
But if for whatever reason your visitors use old browsers, it's tricky. You can feature detect the relative color syntax, but then you must implement fallback colors. You'll end up with multiple color definitions and that's a bad deal. Maybe PostCSS and friends can wrangle the syntax into color definitions, but generally I wouldn't use relative colors if it doesn't work for the majority of your visitors.
/* Feature detect the general relative colors syntax */
@supports (color: hsl(from white h s l)) {
/* safe to use hsl() relative color syntax */
}
/* Feature detect the relative colors syntax with `currentColor` */
@supports (background-color: oklch(from currentcolor calc(l * 4) c h)) {
/* ... */
}
Speaking of the Safari 18 release, being able to use currentcolor
is great, but it requires relative colors. So be sure to check this one first!
@starting-style
and transition-behavior: allow-discrete
allow us to transition the display
property. Finally! What's the state here?
117 | 117 | 117 | Nö | Nope | 18 | 18 | 24.0 | 117 |
117 | 117 | 117 | 129 | 129 | 17.5 | 17.5 | 24.0 | 117 |
Are they safe to use? Yes.
Similar to the JS view transitions, if you're okay with some users not seeing an entry or exit animation, knock yourself out!
Did you know that flexbox layout can lead to data loss?
When your flex container isn't big enough, some elements could be clipped. Not great. The safe
keyword helps to avoid these clippings, and if you want to learn more about this problem, there's another post on this blog with some interactive demos.
115 | 115 | 115 | 63 | 63 | 17.6 | 17.6 | 23.0 | 115 |
Is it safe to use? Yes!
When I checked the last time, you could safely apply the safe keyword, and pre-18 Safari recognized safe; it just didn't have any effect.
To parse a URL in JavaScript, you always had to do a try/catch
dance. While it's not the worst, the great DX looks different.
URL
helps out here.
// Before
let url = null;
try {
url = new URL(input, base);
} catch(e) { }
// Now
const url = URL.parse(input, base);
What's the support?
126 | 126 | 126 | 126 | 126 | 18 | 18 | Non | 126 |
Is it safe to use? Yes, implement a URL
polyfill and drop it once cross-browser support is given.
And these are my highlights of this release. I've never been a fan of screaming "Safari is the new IE" because they're certainly at the forefront of adopting new web features. And it breaks my heart to see Firefox often lacking behind the new'n'fancy.
But overall, the webdev future is bright, friends! And if you want to stay informed, you know what to do.👇
Join 5.5k readers and learn something new every week with Web Weekly.