[turbopack] using `scroll()` does not work while using --turbo

[meesvandongen]

Link to the code that reproduces this issue

https://github.com/meesvandongen/demo-scroll-function

To Reproduce

1. npm i
2. Start the demo with npm run dev
3. scroll down

Current vs. Expected behavior

The page should turn from red to blue, but instead it is green.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32693
  Available CPU cores: 24
Binaries:
  Node: 23.11.1
  npm: 10.9.2
  Yarn: N/A
  pnpm: 8.4.0
Relevant Packages:
  next: 15.3.3 // Latest available version is detected (15.3.3).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

CSS

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

Given this CSS

.page {
  animation: shrink 1s linear both;
  animation-timeline: scroll();
  height: 200vh;
  background-color: green;
}

@keyframes shrink {
  from {
    background-color: red;
  }
  to {
    background-color: blue;
  }
}

The turbopack generated CSS is

animation: 1s linear both page-module__E0kJGG__shrink scroll();`

This is not valid; the animation-timeline property may not be used in the animation shorthand.

This is the case for module imports and non-module imports.

MDN says the following;

The animation shorthand CSS property applies an animation between styles. It is a shorthand for animation-name, ..., and animation-timeline.

But it seems that this is not the current implementation in chrome.

The output using webpack is:

    animation: page_shrink__JKp40 1s linear both;
    animation-timeline: scroll();

[asfaqahmed]

I like to contribute to this Issue

[kvineet002]

I want to contribue

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[Gamez0]

Hello @meesvandongen

I'd like to share what I've found so far.
It looks like turbopack-css is using a Rust-based crate called lightningcss for CSS parsing.
The version of lightningcss in use is the latest one, 1.0.0-alpha.66, so this doesn’t seem to be a simple versioning issue.
From what I’ve seen in the lightningcss source code, it does support animation-timeline, so the problem likely isn’t with lightningcss itself. Instead, the issue seems to lie in how turbopack-css is using lightningcss.

Does this line of investigation seem reasonable? Should I keep digging in this direction?

[akash-dabhi-qed]

The above comment by @Gamez0 does carry some weight, however I think it has to do with the lightningcss's inability to parse the shorthand that is in animation syntax.

I was able to get the code to work in its intended manner by making these changes:

.page {
  animation-name: shrink;
  animation-duration: 1s;
  animation-timing-function: linear;
  animation-fill-mode: both;
  animation-timeline: scroll(); 
  height: 200vh;
  background-color: green;
}

The background-color: green; is rendered inactive with the above changes done, and so is an unwarranted addition to the code.

Also, as noted by @meesvandongen, including animation-timeline syntax in animation would be invalid according to the mdn docs, however the issue here seems to be of the parser not being able to parse the shorthand syntax of animation. This also concludes that it is able to parse animation-timeline: scroll(); correctly.

[Marukome0743]

Duplicate of Next 15.3 breaks scroll animations #78046.

This issue has occured since v15.3.0-canary.15.
Therefore #77313 would be related to it.

[Marukome0743]

An investigation of bug

Next.js uses the following Browserslist configuration by default:

See default Browserslist configuration of Next.js

{
  "browserslist": [
    "chrome 64",
    "edge 79",
    "firefox 67",
    "opera 51",
    "safari 12"
  ]
}

In addition, animation-timeline syntax was supported partially from Chrome 115.

See animation-timeline browser compatibility

So Turbopack should convert the above CSS like below.

See correct Lightning CSS result

However, it made the wrong transforms after v15.3.0-canary.15 version.

See wrong Lightning CSS result

This seems Turbopack doesn't respect the default Browserlist settings.

What do you think? @kdy1