Skip to content
loke.dev
Translucent layered sheets with a broken edge joining into a continuous wave against a dark indigo background.

Fix Astro 7 Stripping Safari CSS Prefixes

Restore Safari-required CSS prefixes in Astro 7 static builds by setting an explicit Vite cssTarget, then verify the generated production CSS.

Published Updated 6 min read

Your Astro page looks correct in Chrome, but a multi-line chip, highlight, or inline badge loses its decoration in Safari after a production build. The source CSS still contains -webkit-box-decoration-break. The generated CSS does not.

This is a current Astro 7 static-build problem, not a Safari cache mystery. A minimal Astro 7.2.0 report reproduced the removal with default settings. The reporter confirmed that an explicit Vite CSS target restores the prefix. Astro closed the proposed framework-level fix because projects are expected to choose their own CSS browser targets.

This guide shows how to confirm the symptom, set a target that matches your browser policy, and add a production-output check so the regression cannot slip back into a deploy.

The quick fix

Add an explicit vite.build.cssTarget to astro.config.mjs. This example uses the browser versions behind Vite 8’s baseline-widely-available target:

import { defineConfig } from 'astro/config';

export default defineConfig({
  vite: {
    build: {
      cssTarget: [
        'chrome111',
        'edge111',
        'firefox114',
        'safari16.4',
        'ios16.4',
      ],
    },
  },
});

Run a clean production build, then search the output for the prefix you need:

pnpm astro build
rg -- '-webkit-box-decoration-break' dist

If your repository uses npm, Yarn, or Bun, keep its existing package manager and run the equivalent Astro build command.

What Astro 7 is doing

The failure is a target-resolution chain across Astro, Vite, and Lightning CSS:

  1. Astro’s static and prerender build uses an ESNext JavaScript target because that build-side JavaScript runs in a modern server environment.
  2. When CSS has no separate target, Vite resolves build.cssTarget from build.target. Vite documents that cssTarget defaults to the same value as build.target.
  3. In this Astro build path, ESNext becomes an empty Lightning CSS target object.
  4. Lightning CSS uses browser targets to decide which vendor prefixes to add or remove. With no browser compatibility requirements represented, it can remove a prefix that your Safari users still need.

The issue report includes the instrumented values and a direct Lightning CSS comparison: omitting targets preserved the prefix, an empty target object removed it, and real Safari targets preserved it. The related Astro pull request was closed rather than merged, so there is no upstream patch to wait for.

The public contracts line up with that diagnosis. Vite’s build options say that build.cssTarget defaults to build.target and that Lightning CSS is the default CSS minifier. Astro’s configuration reference supports passing additional Vite configuration through the top-level vite object. Lightning CSS documents that browser targets control vendor-prefix addition and removal.

Confirm that this is your bug

Do not start by changing targets. First prove that the declaration exists before the build and disappears afterward.

1. Find the source declaration

rg -n -- '-webkit-box-decoration-break|box-decoration-break' src

For the reported case, the source contains both declarations:

.chip {
  -webkit-box-decoration-break: clone;
  box-decoration-break: clone;
}

2. Inspect production output

pnpm astro build
rg -n -- '-webkit-box-decoration-break|box-decoration-break' dist

A failing Astro 7.2.0 build produced only the unprefixed declaration:

.chip{box-decoration-break:clone}

After adding an explicit CSS target, the same build retained both:

.chip{-webkit-box-decoration-break:clone;box-decoration-break:clone}

3. Check the exact toolchain

pnpm astro info
pnpm why vite lightningcss

Record the output in the issue or pull request that changes your browser policy. The local verification for this guide used Node 24.18.0, Astro 7.2.0, Vite 8.2.1, and Lightning CSS 1.33.0.

Pick the right CSS target

A CSS target is a compatibility contract. It tells the minifier which syntax transformations and prefixes the shipped stylesheet needs. Keep it separate from build-side JavaScript requirements.

Use Vite 8’s baseline as an explicit starting point

Vite 8 documents its baseline as Chrome 111, Edge 111, Firefox 114, Safari 16.4, and iOS 16.4. The first configuration in this guide copies those values explicitly, preventing Astro’s ESNext build target from becoming the CSS target.

Support older Safari only when your product requires it

If your support policy includes older Safari releases, set the actual minimum. This smaller configuration also preserved the reported prefix in the verified reproduction:

import { defineConfig } from 'astro/config';

export default defineConfig({
  vite: {
    build: {
      cssTarget: ['safari11'],
    },
  },
});

That snippet is suitable only when Safari 11 is the meaningful floor for your project. Add the Chrome, Edge, Firefox, and iOS targets your application actually supports.

Do not copy a target list without ownership

  • Write the browser policy down in your repository.
  • Use one shared list anywhere your tooling accepts the same target format.
  • Review the list during framework and Vite major upgrades.
  • Test on the oldest supported Safari or an equivalent real-browser service.

The MDN reference for box-decoration-break is useful for checking the property and its compatibility notes. For any other missing prefix, verify that property separately rather than assuming every prefixed declaration should survive.

Add a regression check

A visual test is best because it confirms browser behavior. A small output assertion is still valuable as an early warning for this exact failure.

{
  "scripts": {
    "build": "astro build",
    "check:css-prefix": "pnpm build && grep -R -- '-webkit-box-decoration-break' dist"
  }
}

Run pnpm check:css-prefix in CI. If your generated CSS format can vary, replace the string check with a browser test that renders a wrapped inline element and asserts its decoration in your oldest supported Safari.

Avoid the tempting detours

Do not patch Astro in node_modules

The framework-level pull request was closed, and local package edits disappear on reinstall. The supported configuration surface is the Astro vite object.

Do not disable CSS minification as the default remedy

Turning minification off changes output size and can enter a different code path. It also avoids making the browser contract explicit. Set cssTarget unless you have independently diagnosed a minifier defect.

Do not assume an Astro patch release will change this

The issue was closed on August 12, 2026 with guidance to configure the target in the app. Watch the issue if that policy changes, but treat explicit targets as the current fix.

Keep separate Astro 7.2 failures separate

If your upgrade also causes unchanged pages to rebuild when using the Fonts API, that is a different cache-key regression. Use the focused Astro 7.2 incremental build troubleshooting guide instead of changing CSS targets.

A short rollout checklist

  • Reproduce the missing prefix in a production build.
  • Confirm that the affected browser still needs that declaration.
  • Set vite.build.cssTarget to your real browser minimums.
  • Build again and inspect dist, not only source files.
  • Test the rendered component in the oldest supported Safari.
  • Add an output or browser regression check to CI.

The important distinction is simple: Astro’s build-side JavaScript can target ESNext while browser-facing CSS targets real browsers. Once those concerns are separated, Lightning CSS has the compatibility data it needs to preserve required prefixes.