[robobun]

Problem

• bun build fails on valid @property rules: Unexpected token: url( for url("data:,"), Unexpected token: rgb( for rgb(from currentColor r g b), Invalid value for syntax: "<string>" and "* ".
• A second parser in PropertyRule::parse (src/css/rules/property.rs:117) had no import records. The typed parsers refuse a value that they do not resolve.
• Two build wrong: 1px 2px for <length> | <length>+ as 1px, light-dark() as var(), which Chrome 153 drops.

Fix

• The stylesheet parser reads the value: in place when syntax is known, else after the body.
• A component must match the whole value. Else the value prints as written, like a declaration, with no lowering for old browsers.
• <string> is a syntax name and the syntax string is trimmed at both ends (lightningcss).
• Verified: test/js/bun/css/css.test.ts (13 tests), test/bundler/esbuild/css.test.ts (8), all of test/js/bun/css, test/bundler/css. Self-reviewed: 24 concerns raised, 22 addressed (Notes).

Background

• @property registers a custom property with a syntax (its type) and an initial-value.
• An import record is the bundler's entry for one url().
• Weighed: import records for the second parser (each value is read twice), a color parser signal (css: fold relative colors on the scale of their function, and keep them as written when the fold is not exact #45362: 2 of 15 valid values build).

Downsides

• A typed value that is not valid (foo for <color>) builds as written. It was a build error, which lightningcss tests. A browser drops that rule. Acceptable?
• Some become valid: <integer> with 1.0 prints 1, which Chrome registers. Main prints z-index: 1.0 so too.
• Instructions per rule: 8,404 -> 7,467 (syntax first), 8,940 (initial-value first). Kept as written: 15,904. .text +512 B.

Notes

Behaviour changes

• url() in an initial-value was a build error for each syntax, * too. It is now an import record, as a url() in a declaration: 1 record and 1 asset per url(). A value that a later initial-value replaces leaves 0 records.
• An error in an initial-value is reported at its place in the file. It was reported relative to the value: a.css:1:6 for a value on line 4.
• A typed initial-value whose start matched a component was cut. <length> | <length>+ with 1px 2px built as 1px, and <transform-function> | <transform-list> with rotate(1turn) scale(2) built as rotate(1turn). Both are valid and now print whole. lightningcss 1.33.0 cuts them. <color> with red blue built as red. It is not valid and now prints as written.
• A typed initial-value that no syntax component matches was a build error. It is now printed as written. That covers valid values that the typed parsers do not resolve, and values that are not valid.
• light-dark() in an initial-value was printed as var(--buncss-light, ...) var(--buncss-dark, ...) for the default targets of bun build. It is now printed as light-dark(). For the same targets 2dppx now prints as 2x. Each browser that reads @property (Chrome 85, Firefox 128, Safari 16.4) reads x, #rrggbbaa, space-separated colors and double-position color stops. src/css/compat.rs has no Safari version for the x unit. caniuse has 16.0.
• syntax: "<string>" was Invalid value. It is now a typed syntax (feat: support <string> in @property syntax parcel-bundler/lightningcss#1134).
• syntax: "* " (a space or a tab after the star) was Invalid value. SyntaxString::parse_string (src/css/values/syntax.rs:69) stripped only the start of the string. It now strips both ends, as lightningcss does (trim_matches) and as step 1 of "consume a syntax definition" says.
• initial-value: red; initial-value: foo was a build error. It now prints foo. The last syntax and the last initial-value of a rule win, in Chrome 153 too.
• Not changed: an empty value for a typed syntax and a typed rule with no initial-value are build errors.

Question for a maintainer

A typed initial-value that is not valid has no diagnostic any more. Is that acceptable?

• If the answer is no, the fallback comes out of this PR. Each typed value that no component matches is then a build error, as on main. red blue for <color> is then a build error too, where main builds it as red.
• lightningcss keeps the error and tests it: <color> with 25px and <length> with var(--some-value) are two error_test cases of its test_property. This PR asserts the opposite for both. Its maintainer wrote on @property initial-value parsing error parcel-bundler/lightningcss#921, about a valid value that does not resolve: "We should preserve the original value as is in that case."
• The error is not a check of validity. The typed parsers are the only grammar knowledge there is, and they refuse valid values (RED, oklch(0.5 0 0), calc(1 + 2) for <integer>). Of the 14 typed values of the sample that main refuses, Chrome 153 registers 4.
• The error also misses most values that are not valid. Chrome 153 drops 49 typed bodies of the sample that have a known syntax and a value. Main stops 10 of them, each an rgba(var(--a), var(--b)) in @universal-material/core, whose 8 style sheets main cannot build. Main builds the other 39. 38 of those are a font-relative length under <length>.
• A browser decides in both cases. Chrome 153 and WPT drop the rule. The Editor's Draft of css-properties-values-api ignores only the descriptor: "or else the descriptor is invalid and ignored" (w3c/css-houdini-drafts e1f11c5e6f, 2026-08-06).
• Some values that are not valid also become valid in the built rule, because the print of a token list is not verbatim. A section below lists them. Main does the same to a declaration.
• A warning for each value kept as written fires on every valid value of the measured set. If you want a diagnostic for a subset that can be proven not valid, name the subset. It goes on top of the fallback in SyntaxString::parse_value.
• One subset from the review: warn when the kept value holds no function, var() or env(). Of the 28 values of the measured set that are kept as written, it warns on 11 of the 14 that are not valid and on 1 of the 14 valid ones (RED, until css: match named colors without regard to ASCII case #45092). In the sample it warns on 5 of the 16 bodies that are not valid, and on none of the 40 rgba(var(--a), var(--b)) rules. A warning of the CSS parser has no file name and no line in the output of bun build today.
• That draft also makes each descriptor optional, so the two errors that stay (an empty typed value, a typed rule with no initial-value) reject rules that the draft registers. No engine does that yet. Both are as on main.
• The review thread with this question: css: keep a typed @property initial-value as written when no component matches #45807 (comment)

Measured against Chrome 153 (headless, the source rule and the built rule, pretty and minified, 57 values)

• 10 valid values that are build errors on main (5 with url(), 5 <string> values): each built rule is registered.
• 14 more valid values that are build errors on main, because the typed parsers do not resolve them (rgb(from currentColor r g b), oklch(0.5 0 0), RED, contrast-color(red), <integer> calc(1 + 2), <resolution> calc(1dppx * 2), <image> paint(foo), ...): each built rule registers the same value as its source rule.
• 3 valid values that main cut: each built rule registers the whole value.
• 2 values with light-dark(): each built rule is registered. Chrome drops the built rule of main.
• 13 values that are not valid (foo and var(--x) for <color>, red blue, a bare ident for <string>, ...): each built rule is dropped, as its source rule is. Main stops 9 of them with a build error. It cut the other 4 to a rule that Chrome registered.
• 1 value that is not valid becomes valid: <integer> with 1.0 prints 1. Chrome drops the source rule and registers the built rule.
• 14 values that main builds typed: the same here.
• In total the built rule differs from the source rule in 44 of the 57 values on main and in 8 here: the 1.0 value, and 7 that differ only in spelling (blue as #00f, a bundled url()).

Values that are not valid and become valid (Chrome 153, a second set of 29 values)

• A value kept as written has the print of a declaration. That print is not verbatim, so a value that no component matches can print as a value that a component matches. 20 of the 29 values do. Each is a build error without the fallback. Chrome drops the source rule and registers the built rule.
• The print drops the type of a number: <integer> with 1.0, +1.0, 1e0, 1e2 or -0.0 prints an integer. Also in a list: 1 2.0, 1, 2.0.
• It drops a sign or a comment between two tokens: 1+2 and 1/**/2 print 12 (<integer>, <number>), calc(1+2) prints calc(12), 5/**/0% prints 50%, a/**/b prints ab (<custom-ident>).
• It prints a color as its shortest name: #f00, #808080 and rgb(255 0 0) print red or gray, which <custom-ident> and a keyword syntax accept.
• Main has the same print for a declaration: z-index: 1.0 prints z-index:1, z-index: calc(1+2) prints z-index:calc(12), --x: a/**/b prints --x:ab.
• Main also makes a typed value valid: syntax: "<length>"; initial-value: 5 builds as 5px, which Chrome registers.
• Two ways to stop it, neither in this PR. The first keeps the type of a number and the boundary between two tokens in the token list (src/css/properties/custom.rs). It changes each declaration and each custom property (--x: 1.0 then prints 1.0), and the color case stays. The second keeps the build error for a value that holds number tokens only. It covers 11 of the 20.

Real style sheets (release builds at 017b243, measured in two steps: the parser change, then the fallback)

• The sample: 1,161 distinct top-level @property bodies (42,737 rules) in 1,285 files, from 444 npm packages and 17 GitHub files.
• Bodies, main against this PR: 1,098 print the same. 33 (7,264 rules) fail on main and build here. 0 build on main and fail here. 23 change, each a light-dark(). 7 fail both ways.
• 13 of the 33 build with the parser change: 9 with url() (7,200 rules: url("data:,") in @sap-theming/theming-base-content is 7,192 of them, the others are in 3 GitHub files), and 4 with <string> (12 rules, @material/web and packages that copy it).
• 20 of the 33 (52 rules) build with the fallback: 10 rgba(var(--a), var(--b)) (40 rules, @universal-material/core), oklch(0 0 0 / 0.97) (@ctrl-ui/react), 3 color-mix(in srgb, currentcolor 40%, transparent), and 6 <string> values that are not strings (5 are lists of font names with bare idents).
• The 7: 4 with a syntax name that no draft has (<ratio>, <line-style>), 3 typed rules with no initial-value.
• Files, each built pretty and with --minify: 1,122 give the same bytes. 23 fail on main and build here. 2 differ, in light-dark() only. 0 build on main and fail here. 138 fail both ways for a cause outside this change.
• A real install of @sap-theming/theming-base-content@11.36.5: content/Base/baseLib/sap_horizon/css_variables.css (65 @property rules) exits 1 on main and builds here.
• test/js/bun/css/files/*.css and four files of tailwindcss 4.3.3 (none has @property): 0 of 38 builds differ.
• The trim of the syntax string came after these runs. Each of the 7 bodies that still fail has another cause, so it changes no body of the sample.

Cost (release builds at 017b243, gdb on bun-profile, rule 2 of 4 equal rules, before the trim of the syntax string)

Parse, one call of NestedRuleParser::parse_block, main against the parser change:

rule	instructions	Tokenizer::next_impl	Parser::expect_exhausted	mi_malloc
syntax:'<color>';inherits:false;initial-value:rgb(255 0 0)	8,404 -> 7,467	20 -> 13	4 -> 5	3 -> 2
the same with initial-value first	8,404 -> 8,940	20 -> 20	4 -> 6	3 -> 3
syntax:'<length>';inherits:false;initial-value:0px	4,950 -> 4,808	10 -> 9	3 -> 4	1 -> 1
syntax:'*';inherits:false;initial-value:rgb(from currentColor r g b)	14,528 -> 12,539	49 -> 37	5 -> 4	6 -> 5
syntax:'*';inherits:false	2,445 -> 2,484	6 -> 6	2 -> 2	0 -> 0

The parser change against the parser change with the fallback:

rule	parse, instructions	print, instructions
syntax:'<color>';inherits:false;initial-value:rgb(255 0 0)	7,467 -> 7,467	1,623 -> 1,615
the same with initial-value first	8,940 -> 8,940
syntax:'*';inherits:false;initial-value:rgb(from currentColor r g b)	12,539 -> 12,539	3,620 -> 3,612
syntax:'*';inherits:false	2,484 -> 2,484	1,186 -> 1,161
syntax:'<color>';inherits:false;initial-value:rgb(from currentColor r g b) (kept as written)	error -> 15,904

• Print is one call of PropertyRule::to_css. On main it is 1,622 instructions for the first rule and 1,186 for the rule with no value.
• The rule kept as written: 47 Tokenizer::next_impl calls, 5 Parser::expect_exhausted, 7 mi_malloc, 2 mi_realloc. The same value under syntax:'*': 37, 4, 5 and 2.
• mi_realloc: 2 for each rule with rgb(from currentColor r g b), on main and here. 0 for the others.
• In the sample syntax comes before initial-value in 22,279 of the 22,810 rules that have a value (97.7%). 19,927 of the 42,737 rules have no value.
• A style sheet with no @property (bulma.css): SyntaxString::parse_value calls 0 -> 0, output bytes identical.
• Release binary (llvm-size -A, stripped): .text 81,368,037 -> 81,368,293 -> 81,368,549 B (+256 for the parser change, +256 for the fallback), .rodata 22,598,604 B in all three.
• File system calls of a build with no url() in @property (openat, open, readlink, read, pread64, write, close, getdents64, counted with gdb catch syscall, because strace is not installed here): 77 -> 77 for the first rule of the table, 121 -> 121 for bulma.css.
• The trim of the syntax string is not in these builds. It adds strings::trim_right to each rule: one length check and two byte compares (3 conditional branches) when the string does not end in a space or a tab.

Weighed and set aside

• Lend the import records to the second parser: positions stay relative to the value, and each value is still read twice.
• A signal from the color parser (css: fold relative colors on the scale of their function, and keep them as written when the fold is not exact #45362): the parser counts each relative color that it leaves for the browser, and only then is a typed failure kept as written. 2 of the 15 measured valid values build.
• A token fallback at the failing call, with one more parser (the first form of css: fold relative colors on the scale of their function, and keep them as written when the fold is not exact #45362): url() still fails and the value is read three times.
• Keep the whole rule as an unknown at-rule when it does not parse: it also builds the 7 bodies that still fail, but it prints a warning with no file name, and it lowers light-dark() to var() again.
• A warning for each value kept as written: it fires on each of the 15 measured valid values.

Not in this PR

• A verbatim print of a token list: see the values that become valid, above. css: keep whitespace and comments in token lists #45577 changes how that printer writes blanks. One expected string of this PR has a blank that it moves: rotate(1turn)foo(1).
• A top-level @property that Bun cannot parse fails the whole build, where a browser drops only that rule: an unknown descriptor, an inherits other than true or false, a syntax that does not parse, a typed rule with no initial-value. Main does the same.
• A @property inside @media, @layer, @supports or @scope is kept as an unknown at-rule with a warning, and gets none of these fixes (432 rules of the sample). It still prints light-dark() as var(). lightningcss moved that arm in Allow @property to be nested inside at-rules parcel-bundler/lightningcss#1090.
• bun build --no-bundle has no import record list for the whole sheet, so a url() fails there in each rule (bun build --no-bundle: keep css url() references instead of failing to parse #38528, css: keep a url() in an at-rule prelude as written, and never print the resolved path of a url() #45604).
• A relative url() is resolved against the style sheet, as in a declaration. Chrome 153 resolves a <url> initial-value against the document, and an <image> or * one against the sheet that uses it.
• Integer, boolean and resolution media features fail on a math function (@media (min-resolution: calc(1dppx * 2))) through the same typed parsers.
• Typed values that fold to a wrong value (calc(50% + 1) for <percentage> builds as 0%) are the subject of css: fold relative colors on the scale of their function, and keep them as written when the fold is not exact #45362.
• Four more differences of the syntax string from WPT (css/css-properties-values-api/register-property-syntax-parsing.html). lightningcss has all four. A type name is matched without regard to case: "<LENGTH>" builds and prints "<length>", and WPT has it not valid. A line feed, a carriage return or a form feed around the string is Invalid value. A --foo component is Invalid value. An escape in a component ("banan\61") is Invalid value. WPT has these three valid.

Other PRs

• css: fold relative colors on the scale of their function, and keep them as written when the fold is not exact #45362 pins the old build error in 4 toThrow assertions, and adds a counter to ParserInput so that its own unresolved relative colors stay as written in a typed @property. After this PR that counter is not needed, and the 4 assertions change. The two conflict in property.rs: the second to merge needs a rebase.
• css: keep light-dark() as written under the default browser targets #42009 prints light-dark() as written for the default targets. After it, the print without targets matters for explicit targets and for dppx.
• css: match named colors without regard to ASCII case #45092 (named colors without regard to case) and css: parse number and percentage channels in lab(), lch(), oklab(), oklch(), hsl() and hwb() #45084 (number channels in oklch()) make the typed parser accept more values. Those values then print typed. No expected string of this PR holds such a value.
• css: treat out-of-range and unit-less numeric values as invalid instead of merging or repairing them #42104: a bare number under <length> is read as px, so <length> | <number> with 1.5 prints 1.5px, on main and here.
• Bun.color: return null when input continues past the color #38006: Bun.color("red blue") is "red", the same cut at another call.
• css: keep a typed @property initial-value as written when no component matches #45807 was the fallback as a second PR on top of this one. It is closed, and its commits are here.

Upstream

lightningcss 1.33.0 builds url() in an initial-value and the <string> syntax, and trims the syntax string at both ends. The cases of its test_property are the first test of the @property block.

Self-review

24 concerns raised, 22 addressed. Not done: a tracking issue for the descriptor arms and one for the media features. Both are named above. The review asked for a split into two PRs. They are one PR again, because a maintainer asked for no stacked PRs.

Suites run (bun bd test, debug build with ASAN)

• test/js/bun/css/css.test.ts: 1,327 pass, 0 fail. test/bundler/esbuild/css.test.ts: 64 pass, 0 fail.
• Each other file of test/js/bun/css and test/bundler/css, and test/regression/issue/27117.test.ts, one file at a time: 1,223 pass, 4 fail. The 4 are in css-fuzz.test.ts, a timing test that does not run in CI: 1,000 Bun.build calls do not fit its 10 s limit on a debug build.
• On a release build of main, 12 of the 13 tests of the @property block fail, and 6 of the 8 new bundler cases. The 3 that pass are controls: a syntax string that is not valid stops the build.

---

[human-review] gate passed · iteration 0 · 4 files touched

fails on main (without fix)

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

test/bundler/esbuild/css.test.ts:
(pass) bundler > css/CSSEntryPoint [654.34ms]
(pass) bundler > css/CSSEntryPointEmpty [173.92ms]
(pass) bundler > css/CSSNesting [159.99ms]
(pass) bundler > css/CSSAtImportMissing [162.47ms]
(pass) bundler > css/CSSAtImportSimple [152.92ms]
(pass) bundler > css/CSSAtImportDiamond [167.41ms]
(pass) bundler > css/CSSAtImportCycle [130.49ms]
(pass) bundler > css/CSSUrlImport [127.58ms]
1442 |             }
1443 | 
1444 |             return testRef(id, opts);
1445 |           }
1446 | 
1447 |           throw new Error("Bundle Failed\n" + [...allErrors].map(formatError).join("\n"));
                           ^
error: Bundle Failed
/a.css:1:15: Unexpected token: url(./hi.svg)
      at <anonymous> (/workspace/bun/test/bundler/expectBundled.ts:1447:21)
(fail) bundler > css/CSSUrlInPropertyInitialValue [169.85ms]
(pass) bundler > css/ImportCSSFromJSComposes [204.95ms]
(pass) bundler > css/ImportCSSFromJSComposesFromMissing
... (truncated)

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

test/bundler/esbuild/css.test.ts:
(pass) bundler > css/CSSEntryPoint [1116.36ms]
(pass) bundler > css/CSSEntryPointEmpty [9.35ms]
(pass) bundler > css/CSSNesting [14.80ms]
(pass) bundler > css/CSSAtImportMissing [73.12ms]
(pass) bundler > css/CSSAtImportSimple [25.06ms]
(pass) bundler > css/CSSAtImportDiamond [21.61ms]
(pass) bundler > css/CSSAtImportCycle [11.48ms]
(pass) bundler > css/CSSUrlImport [16.88ms]
1442 |             }
1443 | 
1444 |             return testRef(id, opts);
1445 |           }
1446 | 
1447 |           throw new Error("Bundle Failed\n" + [...allErrors].map(formatError).join("\n"));
                           ^
error: Bundle Failed
/a.css:1:15: Unexpected token: url(./hi.svg)
      at <anonymous> (/workspace/bun/test/bundler/expectBundled.ts:1447:21)
(fail) bundler > css/CSSUrlInPropertyInitialValue [201.03ms]
(pass) bundler > css/ImportCSSFromJSComposes [25.46ms]
(pass) bundler > css/ImportCSSFromJSComposesFromMissingImport [245.00ms]
(pass) bundler > css/ImportCSSFromJSComposesFromNotCSS [20.49ms]
(pass) bundler > css/ImportCSSFromJSComposesCircular [102.61ms]
(pass) bundler > css/ImportCSSFromJSComposesF
... (truncated)

passes on PR (with fix)

ASAN with fix: 73 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/bundler/esbuild/css.test.ts test/js/bun/css/css.test.ts
rustup spent 18s installing the pinned toolchain (nightly-2026-09-15); it was missing or incomplete on this machine
bun test v1.4.4 (367d939d9)

test/bundler/esbuild/css.test.ts:
(pass) bundler > css/CSSEntryPoint [494.23ms]
(pass) bundler > css/CSSEntryPointEmpty [107.00ms]
(pass) bundler > css/CSSNesting [106.57ms]
(pass) bundler > css/CSSAtImportMissing [194.63ms]
(pass) bundler > css/CSSAtImportSimple [118.93ms]
(pass) bundler > css/CSSAtImportDiamond [203.52ms]
(pass) bundler > css/CSSAtImportCycle [134.92ms]
(pass) bundler > css/CSSUrlImport [152.05ms]
(pass) bundler > css/CSSUrlInPropertyInitialValue [243.57ms]
(pass) bundler > css/ImportCSSFromJSComposes [238.81ms]
(pass) bundler > css/ImportCSSFromJSComposesFromMissingImport [733.10ms]
(pass) bundler > css/ImportCSSFromJSComposesFromNotCSS [217.33ms]
(pass) bundler > css/ImportCSSFromJSComposesCircular [242.61ms]
(pass) bundler > css/ImportCSSFromJSComposesFromCircular [237.05ms]
(pass) bundler > css/ImportCSSFromJSCo
... (truncated)

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

23 deps, 204 codegen, 1207 objects in 2060ms

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
268 units: 194 lib, 16 proc-macro (host), 20 custom-build (host), 16 run custom-build, 17 lib (host), 4 run custom-build (host), 1 rlib
[3/4] reconfigure
[1/1564] mkdir stamps
[2/1564] mkdir codegen
[3/1564] gen bake.{client,server,error}.js
-> bake.client.js, bake.server.js, bake.error.js
[4/1564] install /workspace/bun
bun install v1.4.3-canary.1 (367d939d9)

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

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

diff hotspot

src/css/rules/property.rs        |  99 +++++-----
 src/css/values/syntax.rs         |  44 ++++-
 test/bundler/esbuild/css.test.ts | 130 +++++++++++++
 test/js/bun/css/css.test.ts      | 399 ++++++++++++++++++++++++++++++++++++++-
 4 files changed, 619 insertions(+), 53 deletions(-)

gate history · 1 passed · 0 rejected · iteration 0

evidence per changed file

file                              reads  edits  tests
src/css/rules/property.rs             3      3     84
src/css/values/syntax.rs              0      0     84
test/bundler/esbuild/css.test.ts      0      0     41
test/js/bun/css/css.test.ts           1      1     70

[robobun]

^{Updated 10:53 AM PT - Oct 19th, 2026}

✅ @robobun, your commit 5d734557f3a78d08975724a8d2ab8ba4353db8d0 passed in Build #128908! 🎉

---

🧪   To try this PR locally:

bunx bun-pr 45806

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

bun-45806 --bun

[robobun]

Status: closed. The change landed on main in #47025 (7942008).

• Reproduced before the fix with bun build ./a.css --outdir=out. Each of these rules made the build exit 1:
  • @property --u { syntax: "<url>"; inherits: false; initial-value: url("data:,"); } gave error: Unexpected token: url(.
  • @property --c { syntax: '<color>'; inherits: false; initial-value: rgb(from #336699 calc(r + calc(g)) b b); } gave error: Unexpected token: rgb(.
  • @property --s { syntax: "<string>"; inherits: false; initial-value: "a"; } gave error: Invalid value.
  • @property --a { syntax: "* "; inherits: false; } gave error: Invalid value.
• On main at 7942008 each of the four rules builds. The second one prints initial-value: rgb(from #369 calc(r + calc(g)) b b).
• This PR: css: read an @property initial-value on the stylesheet's parser, keep an unmatched value as written #45806. It held the change of css: keep a typed @property initial-value as written when no component matches #45807 too. Both are closed, because css: consolidate the open CSS parser fixes #47025 has the change.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: oven-sh/bun/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 4e1bebde-8cdd-45be-95f1-27c510e55bd2

📥 Commits

Reviewing files that changed from the base of the PR and between 65f3485 and 5d73455.

📒 Files selected for processing: 4

• src/css/rules/property.rs
• src/css/values/syntax.rs
• test/bundler/esbuild/css.test.ts
• test/js/bun/css/css.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 0 remain after this review.

Walkthrough

The CSS syntax parser adds <string> support and stricter full-input parsing for non-repeated components. Property rules now resolve initial values using the final syntax and preserve import state when descriptors are replaced. Tests cover parsing, serialization, validation, and URL resolution.

Changes

Registered CSS property parsing

Layer / File(s)	Summary
Syntax component parsing src/css/values/syntax.rs, test/js/bun/css/css.test.ts, test/bundler/esbuild/css.test.ts	The syntax parser recognizes, parses, serializes, and clones <string> values. It trims syntax definitions, skips leading whitespace, and requires non-repeated components to consume the remaining input. Tests cover string syntax and typed-value parsing.
Property initial-value resolution src/css/rules/property.rs, test/js/bun/css/css.test.ts, test/bundler/esbuild/css.test.ts	Property rules retain parser state for initial values and resolve them using the final syntax. Replaced values discard their import records. Tests cover descriptor ordering, serialization, validation, and URL inlining and resolution errors.

Suggested reviewers: jarred-sumner

Priority: ➖ Normal

Merge Risk: ⚪ Minimal · up to 5d734

No identified issue blocks merging after normal checks.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly identifies the primary parser change and the preservation of unmatched @property initial values. It is specific and related to the changeset.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description is detailed and covers what the PR does, its rationale, behavior changes, limitations, and verification results. It does not use the template headings exactly, but it provides the requ…

Full details: Description check

Explanation

The description is detailed and covers what the PR does, its rationale, behavior changes, limitations, and verification results. It does not use the template headings exactly, but it provides the required information in equivalent sections.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Code review found no issues

No high-confidence issues detected in this change.

[robobun]

One more fix for SyntaxString::parse_string is ready on robobun/9afb4d1d/css-property-syntax-trim. It is one commit (f50de61) on top of 65f3485 and it can be cherry-picked into this PR.

• syntax: "* " (a space or a tab after the star) still fails with Invalid value. The commit changes strings::trim_left to strings::trim at src/css/values/syntax.rs:69, as lightningcss (trim_matches) and the specification do.
• It adds tests for that, for the forms of a <string> value, and for a <string> rule through bun build and Bun.build.

Without the one token, exactly the new whitespace test and the two css/PropertyRuleUniversalSyntaxTrailingSpace cases fail.

[claude]

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

Beyond the inline finding, I also checked two things in this revision and ruled them out: the std::ptr::from_ref::<[u8]>(i.expect_string()?) for the new <string> component is the same safe-code idiom already used for CssString in src/css/values/image.rs, properties/font.rs and properties/animation.rs (the pointer targets the arena-backed input, which outlives the AST), and the import_record_count carry-over around input.reset(&end) in PropertyRule::parse is required because Parser::reset truncates the import record list to the saved state's count.

Extended reasoning...

The change replaces the second detached parser for @ property initial-value with in-place parsing on the stylesheet parser, adds a <string> syntax component, and changes SyntaxString::parse_value so a typed match must consume the whole value and an unmatched value falls through to a TokenList. It touches no security-sensitive surface (CSS parser, no auth or network). One confirmed inline finding on the parse_value fallthrough semantics is posted separately; this note only records what else was examined.

[robobun]

A note for the merge order with #46870.

#46870 keeps a prefixed gradient as tokens when it has at <position>, a radius, bare lengths or a color hint. In an @property rule with syntax: "<image>", such an initial-value is then an Unexpected token error, because the rule has no fallback before this PR. Three rows in #46870 expect that error:

• initial-value: -webkit-radial-gradient(20px 30px, red, blue)
• initial-value: -webkit-radial-gradient(circle at center, red, blue)
• initial-value: -webkit-linear-gradient(red, 50%, blue)

With this PR those values are kept as written, so the three rows need new expectations in the PR that lands second. The two PRs have no text conflict, so only a test run on the merged tree shows the failures.

[Jarred-Sumner]

Landed in #47025 (7942008).

Read an @Property initial-value on the stylesheet's parser, keep an unmatched value as written. 2 real stylesheets