fix(design-system): report radius custom properties under their real name by jackwener · Pull Request #1537 · apache/maka

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.

jackwener · 2026-07-27T11:10:44Z

Closes the last item from the #1520 review — the scanner's substring match on the property name.

The defect

RADIUS_DECL_RE matched border-radius as a bare substring, so this in base.css:

.os-theme-maka {
--os-track-border-radius:var(--radius-surface);
--os-handle-border-radius:var(--radius-control);
}

was scanned as if it were a plain border-radius declaration. Both hold whitelisted tokens today, so nothing failed. But had either held a raw px, the offender would have read:

renderer CSS: border-radius: 4px;

— naming a declaration that exists nowhere in the stylesheet.

Why the fix is not to exclude custom properties

My first instinct was to anchor the match so only real declarations qualify. Looking at what these actually are changed that: .os-theme-maka is OverlayScrollbars' theming API — the library's own CSS consumes those properties and renders a real scrollbar corner.

A radius that reaches the screen should be governed regardless of which declaration spells it. Anchoring would have dropped live coverage to fix a cosmetic bug. So the fix captures the whole property name instead, turning accidental coverage into intentional coverage:

	before	after
`--os-track-border-radius: 4px;`	`border-radius: 4px;` ❌	`--os-track-border-radius: 4px;` ✅
`border-radius: 10px;`	matched	matched
match count on a prefixed property	1	1 (not 2)

The lookbehind is load-bearing

Without (?<![-\w]), a prefixed property also matches at its inner border-radius and gets reported twice. A \b cannot do this job: - is a non-word character, so a word boundary already exists between - and border — the naive anchor is a no-op here.

Tests

One case added, covering all four halves: the custom property is reported, it is named truthfully, the real base.css spelling still passes, longhand custom properties are covered, and one declaration yields exactly one match. Verified the naming assertion fails against the old regex.

Gate

lint · format:check · typecheck · check-dead-css — clean, plus 2891 main-process tests passing.

…name The CSS scanner matched the property name as a bare substring, so `--os-track-border-radius: …` in base.css was scanned as though it were a plain `border-radius` declaration. Both such properties currently hold whitelisted tokens, so nothing failed — but the moment one held a raw px the offender would have read renderer CSS: border-radius: 4px; naming a declaration that does not exist anywhere in the stylesheet, and sending whoever has to fix it looking for the wrong thing. Keeping these in scope is deliberate, not merely tolerated. `.os-theme-maka` is OverlayScrollbars' theming API: the library's own CSS consumes those properties and renders a real scrollbar corner. A radius that reaches the screen is governed no matter which declaration spells it. So the fix is to capture the whole property name rather than to anchor the match and drop the coverage. The lookbehind is load-bearing: without it a prefixed property also matches at its inner `border-radius` and is reported twice. `\b` cannot do this job — `-` is a non-word character, so a word boundary already exists between `-` and `border`. Found while reviewing #1520; deliberately left out of that PR and #1535 as pre-existing and orthogonal. Verified: lint, format:check, typecheck, check-dead-css, and 2891 main-process tests. The new assertion fails against the old regex.