Safari 18 — what web features are usable across browsers?

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.

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?

MDN Compat Data (source)

Browser support info for startViewTransition()

111	111	111	Nope	Nope	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?

MDN Compat Data (source)

Browser support info for Style queries for custom properties

111	111	111	Nein	Nope	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:

• Add ability to test for at-rule preludes
• What is the migration path for Container Queries?

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

119	119	119	128	128	18	Nö	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?

MDN Compat Data (source)

Browser support info for Transitionable when setting `transition-behavior: allow-discrete`

117	117	117	Nope	Nei	18	18	24.0	117

MDN Compat Data (source)

Browser support info for `@starting-style`

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.

MDN Compat Data (source)

Browser support info for `safe` and `unsafe`

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

126	126	126	126	126	18	18	Nope	126

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