Published at
Updated at
Reading time

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!

View transitions level 1

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?

MDN Compat Data (source)
Browser support info for startViewTransition()

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) { /* ... */ }

Style Queries

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?

MDN Compat Data (source)
Browser support info for Style queries for custom properties

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:

currentcolor and system color keywords in relative color syntax

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?

MDN Compat Data (source)
Browser support info for Relative color() syntax

Is it safe to use? Sorta, but not really.

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 yet.

/* 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 to work in the first place.

Creating your color scales in CSS needs to wait a bit.

Animating display

@starting-style and transition-behavior: allow-discrete allow us to transition the display property. Finally! What's the state here?

MDN Compat Data (source)
Browser support info for Transitionable when setting transition-behavior: allow-discrete

MDN Compat Data (source)
Browser support info for @starting-style

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!

Safe flexbox alignment

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.

MDN Compat Data (source)
Browser support info for safe and unsafe

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.parse() 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?

MDN Compat Data (source)
Browser support info for parse() static method

Is it safe to use? Yes, implement a URL.parse() 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.👇

Was this post helpful?
Yes? Cool! You might want to check out Web Weekly for more web development articles. The last edition went out 4 days ago.
Stefan standing in the park in front of a green background

About Stefan Judis

Frontend nerd with over ten years of experience, freelance dev, "Today I Learned" blogger, conference speaker, and Open Source maintainer.

Related Topics

Related Articles