background-attachment: fixed ignored when ancestor uses transform-style: preserve-3d

Short answer

This interaction is not defined in any CSS specification. CSS Backgrounds and Borders Level 3 defines background-attachment: fixed as positioning the background relative to the viewport, but it says nothing about how 3D transform contexts (transform-style: preserve-3d) affect that relationship. The Transforms spec, in turn, does not mention fixed backgrounds. You are in a genuine spec gap, and the engines have filled it differently — so the behavior you see is engine-specific, not a bug in your CSS.

What the engines do today

Based on current stable behavior (verify against your target versions, since interop bugs in this area do get fixed):

• Firefox (Gecko) keeps the background pinned to the viewport, treating preserve-3d as irrelevant to fixed attachment. This matches the plain reading of the Backgrounds spec.
• Chrome (Blink) and Safari (WebKit) treat the fixed background as if it were scroll when it lives inside a 3D rendering context, so it moves with the page.

The likely explanation for Blink/WebKit is that preserve-3d forces a shared 3D rendering context and changes the compositing/paint path for the whole subtree, and the fixed-background compositing optimization is dropped along the way. That is an inference about implementation, not a confirmed fact — the confirmed part is only that the spec does not mandate either behavior and the engines disagree.

Fixes that keep preserve-3d

You do not have to remove preserve-3d from the ancestor. Three scoped options, in order of preference:

1. Move the background to a fixed-position pseudo-element outside the 3D subtree. A common pattern is a position: fixed; inset: 0; z-index: -1 element (or pseudo-element on a wrapper above the 3D context) carrying the hero image. This sidesteps the undefined interaction entirely and is the most robust across engines.
2. contain: paint on the element that owns the fixed background. This creates an independent paint containment boundary and, in practice, restores fixed behavior in Blink/WebKit. Caveat: paint containment clips overflow and can affect absolutely positioned descendants and hit-testing, so check the hero section's children.
3. transform: none on the background's subtree (i.e., ensure no transform or preserve-3d applies between the background element and the viewport). This only works if that subtree genuinely needs no 3D transforms — it will silently disable any 3D animation placed there later.

Verify it yourself

<div style="transform-style:preserve-3d">
  <div style="height:2000px">
    <div style="height:500px;background:url(hero.jpg) fixed"></div>
  </div>
</div>

Scroll the page in each browser: if the image moves with the content, you are seeing the Blink/WebKit behavior. Then add contain: paint to the inner div and confirm the image stays stationary in all three engines.

Which engine is the reference for an interop issue?

None, formally — with no spec text, no engine is 'correct'. Practically, Firefox's behavior matches the literal wording of Backgrounds 3 (viewport-relative), so file the issue against the CSS Working Group (csswg-drafts) asking for the interaction to be defined, using Gecko as the proposed reference behavior, and cross-file against Blink/WebKit pointing at the spec issue. Include your reduced test case; interop issues with minimal reproductions get traction far faster.