[robobun]

Stacked on #46697. No user reported this.

Problem

• A background or background-image list gets a vendor prefix on every layer of its fallback declaration. radial-gradient(circle at top left, red, blue) beside image-set("a.png" 1x) gives -webkit-radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("a.png") 1x).
• Chrome and Edge 80 to 112 need that declaration and reject its gradient.
• Cause: get_fallbacks_image (src/css/small_list.rs:87-150) ORs the prefixes that each layer needs, then prefixes every layer.

Fix

• prefix_helper decides per layer. An unprefixed gradient takes the prefix only if it needs it.
• An author-prefixed gradient still takes the prefix. image-set() still takes -webkit-, never -moz- or -o-.
• A prefixed declaration that changes no layer is not printed. The unused VendorPrefix::from_name_str is removed.
• Verified: test/js/bun/css/css.test.ts (21 tests fail without the fix), other CSS suites. Self-reviewed: 36 concerns raised, 33 addressed (Notes).

Background

• A prefixed gradient function takes the 2011 grammar: position first, no at, no color hint. bun prints those parts in the standard grammar only.
• Considered a guard in Image::get_prefixed: the union is in the list routine. Considered the same test for image-set(): it loses -webkit- beside an author -webkit- gradient. lightningcss has the same union.

Downsides

• Browsers older than the targets: -webkit-linear-gradient(..), linear-gradient(..) gets no all--webkit- copy now, and Chrome 10 to 25 read only that copy.
• Release .text: +256 bytes. flush with no background: 20 instructions (was 18). get_fallbacks for a list that needs no prefix: 165 (was 282).
• Not fixed: for Chrome 9 and older, a list with no gradient is still printed twice.

Notes

The base of this PR is the branch of #46697, because this PR changes five expectations that #46697 adds. The Rust applies to main as is. When #46697 merges, this branch moves onto main.

Repro (bun 1.4.3, 1.4.4, main 5c6d4e2, default browser targets):

printf 'a{background-image:radial-gradient(circle at top left,red,blue),image-set("data:image/png;base64,AA==" 1x)}' > a.css
bun build a.css --outdir=o && cat o/a.css

/* before */
a {
  background-image: -webkit-radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("data:image/png;base64,AA==") 1x);
  background-image: radial-gradient(circle at 0 0, red, #00f), image-set("data:image/png;base64,AA==" 1x);
}
/* after */
a {
  background-image: radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("data:image/png;base64,AA==") 1x);
  background-image: radial-gradient(circle at 0 0, red, #00f), image-set("data:image/png;base64,AA==" 1x);
}

CSS.supports('background-image', v) in headless Chrome 153, which still has the parser for the prefixed functions:

INVALID -webkit-radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("a.png") 1x)
VALID   radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("a.png") 1x)
INVALID -webkit-linear-gradient(red, 30%, #00f), -webkit-image-set(url("a.png") 1x)
VALID   linear-gradient(red, 30%, #00f), -webkit-image-set(url("a.png") 1x)

The old copy is invalid when the gradient has at <position> or a color hint. It is valid but drawn differently when a radial gradient has an explicit size: -webkit-radial-gradient(20px, red, blue) reads 20px as a position. #46697 corrects the direction of a linear copy. This change removes the copy in all of these cases.

Reach. Of the default targets, Chrome and Edge 80 to 112 and Opera 67 to 98 need -webkit-image-set(). #40369 raises the default targets to Chrome and Edge 111, so the case then remains for versions 111 and 112. With those targets the handler also drops an author -webkit-image-set() declaration that comes before the standard one and generates it again, so the copy reaches a correct hand-written fallback too. One row covers that. #40368 adds a cssTarget option, which makes the older targets reachable.

The rule. prefix_helper builds the declaration for one prefix and pushes it only when a layer changed. In that declaration:

• An unprefixed gradient takes the prefix only when it needs it.
• A gradient that the author prefixed takes it. The prefixed syntaxes match, and an engine rejects the prefix of another vendor.
• image-set() takes -webkit- in each -webkit- declaration, as before. It never takes -moz- or -o-.

When no layer is unprefixed and a declaration was generated, the last one replaces the written list, as before.

Input	Targets	Before	After
linear-gradient(to right,red,blue), image-set("a.png" 1x)	default	first declaration has a -webkit-linear-gradient()	first declaration has linear-gradient(to right, ...)
radial-gradient(red,blue), image-set("a.png" 1x)	firefox 15, chrome 25, opera 12	also -moz-image-set(...) and -o-image-set(...)	-moz-radial-gradient(...), image-set(...) and -o-radial-gradient(...), image-set(...)
-webkit-linear-gradient(left,red,blue), url(a.png)	default	the same declaration twice	once
-moz-linear-gradient(left,red,blue), image-set("a.png" 1x)	default	-webkit-linear-gradient(left, ...), -webkit-image-set(...), then -moz-linear-gradient(...), -moz-image-set(...), then the value	-webkit-linear-gradient(left, ...), -webkit-image-set(...), then the value
-webkit-linear-gradient(left,red,blue), -moz-linear-gradient(left,red,blue)	default or none	one declaration per prefix	the same
-webkit-linear-gradient(left,red,blue), image-set("a.png" 1x)	none	-webkit-linear-gradient(left, ...), -webkit-image-set(...), then the value	the same
linear-gradient(red,blue), image-set("a.png" 1x)	chrome 20	-webkit-linear-gradient(...), -webkit-image-set(...), then the value	the same

Tests. Under background: 26 rows, 4 tests that check each pair of 11 layers (no declaration twice, no -moz-image-set() or -o-image-set()), and 1 bun build test for the repro. #46697 has rows that pin the copy this PR removes at the default targets. Three of them move to Chrome 25, where the gradient itself needs -webkit-, with the same expected output. The layers strings of its bun build test now expect the unprefixed gradient. Without the fix, 21 tests fail: 15 of the rows, the 4 pair tests and the 2 bun build tests.

Measurements. Base is the branch of #46697 (6494118). Rows come from cssInternals.prefixTest. The per-call numbers come from release builds of both trees (gdb on bun-profile, third call of a loop).

• Lists that must not change: 0 of 396 rows differ (22 single-layer and same-need lists, 9 target sets, both properties). A lone image-set(): 0 of 54 rows differ.
• Stylesheets: 0 of 15 in test/js/bun/css/files differ under bun build. 0 of 591 rows differ for the 197 .css files of the checkout at 3 target sets.
• Chromium (headless Chrome 153, CSS.supports), 74 mixed-list rows at the default targets: the first declaration is accepted in 66 (was 56). Without the declarations that have an unprefixed image-set(), which Chromium 80 to 112 cannot read, 66 rows have an accepted declaration (was 58). With no targets the two counts are 62 (was 60) and 30 (was 30). No row loses an accepted declaration.
• Mixed lists, 666 rows (37 lists, 9 target sets, both properties): rows with -moz-image-set() or -o-image-set() 0 (was 114). Rows with the same declaration twice 10 (was 76). All 10 have a target that needs -webkit-gradient(). No row has more declarations than before. No row loses every -webkit-image-set() that it had.
• Of those 666 rows, 52 lose a generated declaration and gain nothing. In each, that declaration only put a prefix on a gradient that does not need it with those targets. Example: -webkit-linear-gradient(left,red,blue), linear-gradient(red,blue) at the default targets had an all--webkit- copy. Chrome 10 to 25 read that copy, and they are not targets.
• Targets that need -webkit-gradient() (chrome 8, safari 6, chrome 8 + firefox 4 + opera 11.5): the -webkit-gradient() declarations differ in 0 of 372 rows.
• Declarations after a build of bun's own output, 4 times: url(b.png), image-set("a.png" 1x) 2>2>2>2 (was 2>3>4>5). radial-gradient(...), -webkit-image-set(...) 1>1>1>1 (was 2>3>5>9). -webkit-linear-gradient(left,red,blue), url(a.png) 1>1>1>1 (was 2>3>4>5). The repro 2>2>2>2 (was 2>2>2>2).
• Release .text: 82,259,017 bytes (was 82,258,761). The stripped binary keeps its size. get_fallbacks::<Background> 2755 B (was 2610), BackgroundHandler::flush 9520 B (was 9244), the two prefix_helper copies 926 B and 772 B (were 848 and 807). With the pass inline in the loop, an earlier revision grew .text by 3,840 bytes, so prefix_helper is #[inline(never)].
• Instructions per call for a list that needs no prefix: get_fallbacks for background:url(a.png) 165 (was 282), indirect jumps 0 (was 3). BackgroundHandler::flush for background-image:url(a.png) 416 (was 527). A flush with no background property: 20 (was 18), because the compiler now stores two arguments before the early return.
• mi_malloc family calls per flush: background:-webkit-linear-gradient(left,red,blue) 7 (was 8). The same as background-image 3 (was 4). background:url(b.png),image-set("a.png" 1x) 8 (was 8). background:url(a.png) 1 (was 1).
• Targets::prefixes calls per flush: the repro 4 (was 2). A list with three prefixed declarations 8 (was 2). A url() list 0 (was 0).

Self-review, not taken

• A rebase onto main. Each merge order is correct only if css: read a prefixed linear-gradient direction in the 2011 syntax #46697 first changes the five expectations, and that PR is ready for review as it is.
• The image-set() rule limited to a list in which an unprefixed layer needs -webkit-. A --target=bun build of -webkit-linear-gradient(left,red,blue), image-set("a.png" 1x) then loses the -webkit-image-set() declaration that main prints.
• New issues for the items under "Not changed here". This PR files none.

Related PRs

• css: eliminate all unreachable!() via type-level hardening #33332 (draft) rewrites prefix_helper and also deletes VendorPrefix::from_name_str. It conflicts textually with this PR.
• css: keep a prefixed gradient that uses the standard syntax as written #46870 keeps a prefixed radial gradient that has a length or at <position> as tokens. No row of this PR has such a value as input. css.test.ts passes on a tree that has both PRs (1650 tests).
• css: print explicitly prefixed selectors as written in every vendor prefix pass #42106, css: stop emitting :-webkit-any() copies of :is() that outrank the original rule #42029 and css: print the vendor prefix on downleveled :any-link, :read-only, :read-write, :placeholder-shown and :autofill #42131 ask the same kind of question for the selector printer: what a generated vendor prefix pass does to a part that does not need the prefix.
• lightningcss has the same union (impl FallbackValues for SmallVec<[T; 1]>). A search found no upstream report of it, and this PR files none.

Not changed here

• The -webkit-gradient() declaration, for targets such as Chrome 9 or Safari 6. No release build can select such targets. A list with no gradient to convert still gets a copy of itself there (Duplicate 'image-set' generated with certain browserslist targets parcel-bundler/lightningcss#436). The single-image path (Image::get_fallbacks, used by border-image) has the same copy. That declaration still leaves out a -webkit-gradient() that the author wrote.
• BackgroundHandler keeps each declaration that has a prefixed layer in a stash and also flushes it (background.rs:816-824, :1139-1151). A list that keeps an author-prefixed layer beside a layer that needs a generated prefix still gains a declaration when a same-selector rule merges: -moz-linear-gradient(left,red,blue), image-set("a.png" 1x) gives 2 declarations, then 3 after the merge (was 3, then 5). lightningcss does the same.
• A block with two declarations of the property. The handler writes the held value first when a target cannot read the later one, and image-set() needs Firefox 88 against the default Firefox 78 (flush_helper!, background.rs:619-630). The later value then gets no generated fallback. background-image: image-set("a.png" 1x); background-image: image-set("b.png" 1x) gives -webkit-image-set() for a.png only. css: keep an earlier gap or flex-basis declaration when a target lacks the later one #46694, css: keep border-image and border in source cascade order within a rule #42018 and css: keep an earlier transform or translate declaration when a target does not support the later one #45908 change the same policy in other handlers.
• An image-set() with type() or a gradient option still gets a -webkit-image-set() copy with those parts. A comment in ImageSetOption::to_css says that -webkit-image-set() does not support them.
• A layer list that is not fully parsed (a var() layer) and the list-style-image, cursor and content properties do not pass through this routine. They get no -webkit-image-set() copy.
• A prefixed gradient that the targets need (Chrome 25 and older) still prints the standard grammar for a radial position and for a color hint.

---

[human-review] gate passed · iteration 1 · 3 files touched

fails on main (without fix)

ASAN without fix: 21 failed, 72 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/bun/css/css.test.ts
bun test v1.4.4 (367d939d9)

test/js/bun/css/css.test.ts:
Output .flexrow {
  flex-direction: row;
}

.flexcol {
  flex-direction: column;
}

.hello {
  flex-wrap: wrap;
}

.world {
  flex-wrap: nowrap;
}

(pass) css tests > .flexrow {
	flex-direction: row;
}

.flexcol {
	flex-direction: column;
}

.hello {
	flex-wrap: wrap;
}

.world {
	flex-wrap: nowrap;
} [4.23ms]
Output .foo {
  content: "+";
}

(pass) css tests > .foo {
  content: "\2b";
} [1.09ms]
Output div {
  --foo: 1 1 1 #0101011a, 2 2 2 #02020233;
  --bar: 1 1 1 #01010116, 2 2 2 #02020233;
}

(pass) css tests > custom property cases > div {
        --foo: 1 1 1 rgba(1, 1, 1, 0.1), 2 2 2 rgba(2, 2, 2, 0.2);
        --bar: 1 1 1 #01010116, 2 2 2 #02020233;
      } [1.19ms]
Output :root {
  --my-color: red;
  --my-bg: white;
  --my-font-size: 16px;
}

.element {
  color: var(--my-color);
  background-color: var(--my-bg);
  font-size: var(--my-font-size);
}

(pass) css tests > custom property cases > :root {
        --my-color: red;
        --my-bg: wh
... (truncated)

release without fix: 160 failed, 72 skipped
bun test v1.4.3-canary.1 (367d939d9)

test/js/bun/css/css.test.ts:
Output .flexrow {
  flex-direction: row;
}

.flexcol {
  flex-direction: column;
}

.hello {
  flex-wrap: wrap;
}

.world {
  flex-wrap: nowrap;
}

(pass) css tests > .flexrow {
	flex-direction: row;
}

.flexcol {
	flex-direction: column;
}

.hello {
	flex-wrap: wrap;
}

.world {
	flex-wrap: nowrap;
} [0.66ms]
Output .foo {
  content: "+";
}

(pass) css tests > .foo {
  content: "\2b";
} [0.15ms]
Output div {
  --foo: 1 1 1 #0101011a, 2 2 2 #02020233;
  --bar: 1 1 1 #01010116, 2 2 2 #02020233;
}

(pass) css tests > custom property cases > div {
        --foo: 1 1 1 rgba(1, 1, 1, 0.1), 2 2 2 rgba(2, 2, 2, 0.2);
        --bar: 1 1 1 #01010116, 2 2 2 #02020233;
      } [0.07ms]
Output :root {
  --my-color: red;
  --my-bg: white;
  --my-font-size: 16px;
}

.element {
  color: var(--my-color);
  background-color: var(--my-bg);
  font-size: var(--my-font-size);
}

(pass) css tests > custom property cases > :root {
        --my-color: red;
        --my-bg: white;
        --my-font-size: 16px;
      }
      .element {
        color: var(--my-color);
        background-color: var(--my-bg);
        font-size: 
... (truncated)

passes on PR (with fix)

ASAN with fix: 72 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/bun/css/css.test.ts
bun test v1.4.4 (367d939d9)

test/js/bun/css/css.test.ts:
Output .flexrow {
  flex-direction: row;
}

.flexcol {
  flex-direction: column;
}

.hello {
  flex-wrap: wrap;
}

.world {
  flex-wrap: nowrap;
}

(pass) css tests > .flexrow {
	flex-direction: row;
}

.flexcol {
	flex-direction: column;
}

.hello {
	flex-wrap: wrap;
}

.world {
	flex-wrap: nowrap;
} [2.95ms]
Output .foo {
  content: "+";
}

(pass) css tests > .foo {
  content: "\2b";
} [1.28ms]
Output div {
  --foo: 1 1 1 #0101011a, 2 2 2 #02020233;
  --bar: 1 1 1 #01010116, 2 2 2 #02020233;
}

(pass) css tests > custom property cases > div {
        --foo: 1 1 1 rgba(1, 1, 1, 0.1), 2 2 2 rgba(2, 2, 2, 0.2);
        --bar: 1 1 1 #01010116, 2 2 2 #02020233;
      } [0.94ms]
Output :root {
  --my-color: red;
  --my-bg: white;
  --my-font-size: 16px;
}

.element {
  color: var(--my-color);
  background-color: var(--my-bg);
  font-size: var(--my-font-size);
}

(pass) css tests > custom property cases > :root {
        --my-color: red;
        --my-bg: wh
... (truncated)

release with fix: 72 skipped
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped)
  target       linux-x64-gnu
  build type   Release
  build dir    ./build/release
  revision     a875325ca8
  features     lto, baseline

23 deps, 396 codegen, 1302 objects in 1284ms

ninja: Entering directory `/workspace/bun/build/release'
[1/4] fetch lolhtml
[lolhtml] up to date
[2/4] fetch rust-argon2
[rust-argon2] up to date
[2/4] cargo plan → /workspace/bun/build/release/rust-target/plan.json
282 units: 194 lib, 16 proc-macro (host), 27 custom-build (host), 23 run custom-build, 17 lib (host), 4 run custom-build (host), 1 rlib
[3/4] reconfigure
[1/1672] mkdir stamps
[2/1672] mkdir codegen
[3/1672] gen bake.{client,server,error}.js
-> bake.client.js, bake.server.js, bake.error.js
[4/1672] install /workspace/bun
bun install v1.4.3-canary.1 (367d939d9)

Checked 22 installs across 44 packages (no changes) [1000.00ms]
[5/1672] install /workspace/bun/packages/bun-error
bun install v1.4.3-canary.1 (367d939d9)

Checked 1 install across 2 packages (no changes) [49.00ms]
[6/1672] rustc unicode_ident 
[7/1672] rustc unicode_xid 
[8/1672] gen string-map defines_table
[9/1672] rustc heck 
... (truncated)

diff hotspot

src/css/lib.rs              |  14 --
 src/css/small_list.rs       |  68 +++++---
 test/js/bun/css/css.test.ts | 414 +++++++++++++++++++++++++++++++++++++++++++-
 3 files changed, 453 insertions(+), 43 deletions(-)

gate history · 1 passed · 0 rejected · iteration 1

evidence per changed file

file                         reads  edits  tests
src/css/lib.rs                   1      1     75
src/css/small_list.rs           10     11     76
test/js/bun/css/css.test.ts      7     15     75

[robobun]

^{Updated 7:50 AM PT - Oct 25th, 2026}

✅ @robobun, your commit a875325ca886df62891d1486efeb50b9f38a7c22 passed in Build #132607! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 46755

That installs a local version of the PR into your bun-46755 executable, so you can run:

bun-46755 --bun

[robobun]

Status: closed, not merged. #47025 consolidated the open CSS parser pull requests and did not take this change (see the comment of Jarred-Sumner below). Reopen this PR if the input shows up in real CSS.

The reproduction, for the record (bun 1.4.3, bun 1.4.4 and main 5c6d4e2, default browser targets):

printf 'a{background-image:radial-gradient(circle at top left,red,blue),image-set("data:image/png;base64,AA==" 1x)}' > a.css
bun build a.css --outdir=o && cat o/a.css

The first declaration of the output is -webkit-radial-gradient(circle at 0 0, red, #00f), -webkit-image-set(url("data:image/png;base64,AA==") 1x). CSS.supports("background-image", ...) is false for it in headless Chrome 153. With this PR the gradient stays radial-gradient(circle at 0 0, red, #00f) and CSS.supports is true.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline findings, I also checked the other callers of small_list::get_fallbacks for the same per-layer prefix change: only the two BackgroundHandler::flush sites in src/css/properties/background.rs use it, and border-image goes through the single-image Image::get_fallbacks path, so it is unaffected. The deleted VendorPrefix::from_name_str has no remaining callers in src/css.

Extended reasoning...

The change rewrites vendor-prefix fallback generation for background and background-image layer lists in src/css/small_list.rs, adds an early return in Gradient::get_legacy_webkit, deletes an unused helper in src/css/lib.rs, and adds a block of prefix tests in test/js/bun/css/css.test.ts; it touches no security-sensitive surface. Two confirmed findings are posted inline, so the inline comments already signal that a human look is needed; this note only records the sibling call sites and dead-code deletion that were checked and ruled out.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/css/small_list.rs — Users targeting legacy WebKit (chrome 8, safari 5) still get the same background-image declaration printed twice for a list such as -webkit-image-set(url(a.png) 1x), url(b.png). The legacy block at src/css/small_list.rs:116 is gated on the union prefixes, which an author-prefixed image-set satisfies, and src/css/values/image.rs:139 deep-clones every non-gradient layer, so an identical list is pushed at src/css/small_list.rs:130. The PR replaced the union gate for prefix_helper with unprefixed_needs but left this one. Fix: push the legacy list only when at least one layer was actually converted by get_legacy_webkit, or gate it on unprefixed_needs plus author-prefixed gradients, covering every list with no convertible gradient. [also at: src/css/values/gradient.rs:185 - Users building for legacy WebKit targets (Chrome 4-9, iOS Safari 3.2-6) now get the same background-image declaration printed twice when a list mixes an author -webkit-gradient() with layers that have no legacy form. src/css/values/gradient.rs:183 now returns the -webkit-gradient() unchanged, and src/css/small_list.rs:123 deep-clones url()/image-set layers, so the legacy list at src/css/small_list.rs:130 can equal the written value with no dedup downstream.]

  Why this was flagged

  Input: a background or background-image list where no layer is a standard gradient but one layer carries -webkit- (e.g. -webkit-image-set(url(a.png) 1x), url(b.png)), under browser targets for which Feature::is_webkit_gradient is true (chrome < 10, safari <= 5.0, ios_saf <= 4). At src/css/small_list.rs:91-92 the author image-set contributes WEBKIT to prefixes (targets.rs:128 returns the author prefix unchanged), so the gate at :116 passes. The loop at :122-126 calls Image::get_legacy_webkit, which at src/css/values/image.rs:139 returns a deep clone for every non-gradient layer, so images equals the original list and :130 pushes it. The caller prints it, then prints the original: the same declaration twice. The PR's own goal is to stop emitting redundant relabelled copies, and it introduced unprefixed_needs at :87 for prefix_helper, but the legacy gate still uses the union. Base also emitted this duplicate (plus a third copy from prefix_helper). Remedy: track whether any get_legacy_webkit call changed a layer and only push when it did.

  Verification: Pre-existing: the base emits it three times; the PR cuts it to two but leaves the legacy-webkit path on the union gate. Trigger: an author -webkit-image-set() beside an unprefixed non-gradient layer under targets where Feature::is_webkit_gradient holds. src/css/small_list.rs:116 gates on the union prefixes, so image.rs:139 deep-clones every layer and line 130 pushes an identical copy.

[robobun]

The review has two findings. 35a3c7a handles the first one. This PR does not change the second one.

• List with two author prefixes. The list keeps one declaration per prefix, as on main. The inline thread has the details.
• Repeated declaration with targets that need -webkit-gradient(). -webkit-image-set(url(a.png) 1x), url(b.png) at chrome 8 is now printed twice (three times on main), because a prefix pass that changes no layer is no longer printed. The copy that remains comes from the -webkit-gradient() pass: Image::get_legacy_webkit returns a clone of each layer that is not a gradient, and the pass pushes that list. lightningcss has the same pass (Duplicate 'image-set' generated with certain browserslist targets parcel-bundler/lightningcss#436), and the single-image path (Image::get_fallbacks) prints the same copy. No release build can select those targets (Targets::for_bundler_target), so this PR leaves both paths as they are on main. The second instance in the finding came from an early return that the first revision added to Gradient::get_legacy_webkit. That early return is gone.

[claude]

I reviewed the latest push (35a3c7a) and found no bugs; it resolves the mixed-author-prefix case I flagged earlier, and the new test row pins it. Because this deliberately diverges from the lightningcss union behavior on a couple of judgment calls (an unprefixed image-set() always takes -webkit- inside a webkit declaration; a two-vendor author list is replaced by the last generated one), a human look at those choices is still worthwhile.

What was reviewed:

• Traced prefix_helper and the trailing first_prefixed/rgb branches against get_necessary_prefixes, get_vendor_prefix, get_prefixed, and Targets::prefixes for same-prefix, mixed-prefix, legacy -webkit-gradient()-present, and rgb-present/absent lists; each matches the old output or the new test expectations.
• Confirmed VendorPrefix::from_name_str has no remaining callers and has_vendor_prefix is still used by BackgroundHandler.
• Note the description is now stale in two places: src/css/values/gradient.rs is unchanged from base at HEAD, so an author -webkit-gradient() layer is still dropped from the legacy declaration (pre-existing, not a regression), and the two-author-prefix row now yields one declaration per vendor rather than "as written".

Extended reasoning...

The diff touches the CSS vendor-prefix fallback generator for background image layer lists (src/css/small_list.rs), deletes an unused panicking helper in src/css/lib.rs, and adds ~400 lines of tests including a pairwise layer matrix. It touches no security-sensitive surface. The second commit addressed the one inline finding from the prior run, and tracing every branch combination against the helper implementations found no behavioral regression. Deferring rather than approving because the change intentionally departs from the lightningcss reference on design points a maintainer should weigh, it is stacked on another open PR, and the PR description no longer matches the code in two places.

[robobun]

No code change follows from this review. Two notes for the reader.

Description. I updated the title and the description for 35a3c7a after the push. They now say these two things:

• The -webkit-gradient() pass is as on main. An author -webkit-gradient() layer is still left out of that declaration (Notes, "Not changed here").
• A list in two author prefixes keeps one declaration per prefix.

Deviations from lightningcss. The two behaviors that the review names are not deviations. Main and lightningcss do the same. image-set() takes -webkit- in a -webkit- declaration. The last generated list replaces a written list that has no unprefixed layer. The deviations are these three:

• An unprefixed gradient takes a prefix only when the targets say that it needs the prefix. A prefixed gradient function takes the 2011 grammar, so a copy such as -webkit-radial-gradient(circle at 0 0, ..) is invalid.
• image-set() does not take -moz- or -o-. The prefix table gives it only -webkit- (src/css/prefixes.rs:1812).
• A prefixed declaration that changes no layer is not printed. It is equal to a declaration that follows it.

The Downsides section names the one kind of output that a browser older than the targets loses.

[robobun]

A note for the merge order with #46870.

#46870 stops typing a prefixed radial gradient that has at <position>, a radius or bare lengths. Such a value is then kept as tokens. The two PRs have no text conflict.

Two rows that this PR adds use such a value as typed input, both at chrome: 8:

• background-image: -moz-radial-gradient(20px, red, blue), radial-gradient(20px, yellow, red)
• background-image: -webkit-radial-gradient(20px, lab(50% 20 30), blue)

They need new expectations in the PR that lands second. Git merges css.test.ts with no conflict marker, so only a test run on the merged tree shows the two failures.

[claude]

I re-reviewed the latest push and found no bugs; the mixed-author-prefix case I raised earlier is now handled (an author-prefixed gradient is relabelled in every generated declaration, with a test row for the -webkit-/-moz- pair). Because this deliberately diverges from lightningcss's per-list prefixing and drops the all--webkit- copy that Chrome 10-25 relied on, a maintainer's call on that tradeoff would still be worthwhile.

What was reviewed:

• Traced prefix_helper and the first_prefixed/rgb tail branches in src/css/small_list.rs against the old control flow for single-layer, legacy -webkit-gradient(), RGB-fallback-without-unprefixed-layer, and two-vendor lists — output matches the old code where no layer's prefix changes, and the res.pop() can no longer consume the legacy list.
• Checked the retargeted defaultTargets -> chrome25 rows: the direction property they pinned is still asserted, and the new default-target behavior is asserted alongside.
• Confirmed VendorPrefix::from_name_str has no remaining callers and that Gradient::WebkitGradient (need = NONE) is never relabelled by the new gradient arm.

Extended reasoning...

The diff touches src/css/small_list.rs (per-layer vendor-prefix decision in get_fallbacks_image), removes an unused panicking helper from src/css/lib.rs, and adds ~400 lines of tests in test/js/bun/css/css.test.ts; no security-sensitive surface is involved. The code is small and I traced each branch against the previous behavior without finding a regression, and the prior inline concern about two-vendor lists was addressed in commit 35a3c7a. The decision to defer rather than approve rests on the change being a deliberate output-semantics tradeoff (dropping the all-webkit copy for pre-26 Chrome, diverging from lightningcss) that a CSS maintainer should weigh, not on any defect found. No CODEOWNERS entry covers these paths and no third-party objections are outstanding.

[robobun]

No code change follows from this review. The tradeoff that it names is in the description, under Downsides: a list such as -webkit-linear-gradient(..), linear-gradient(..) gets no all--webkit- copy now, and only Chrome 10 to 25 read that copy.

The last push (a875325) changes tests only. Two rows at Chrome 8 had an author-prefixed radial gradient with a bare length as input. #46870 changes how such a value is parsed. The rows now use linear gradients, which take the same path through the list routine. On a tree that has this PR and #46870, css.test.ts has 1650 passes and 0 failures. So the note of Oct 25 about new expectations no longer applies to this PR.

[Jarred-Sumner]

Not taken in #47025 (7942008), which consolidated the open CSS parser pull requests. The fix is right, but none of the 10,116 real stylesheets it was checked against has this input, and it is not new syntax. Reopen it if the input shows up in real CSS.

[robobun]

Understood. Two facts for a reopen:

• Input. A background or background-image list that has image-set() beside a gradient with at <position>, an explicit radial size, or a color hint. With the default targets, the -webkit- copy of that gradient is invalid or is drawn differently.
• Branch. robobun/cbe6411d/css-per-layer-image-prefixes at a875325. It was stacked on css: read a prefixed linear-gradient direction in the 2011 syntax #46697, so it needs a rebase onto main after css: consolidate the open CSS parser fixes #47025.