CSS Color Level 5 Relative Color Syntax in Less#

CSS Color Level 5 introduced relative color syntax — e.g. rgb(from var(--surface) r g b / 0.9) — which lets a color function derive its channel values from an existing color. Less must pass these expressions through to the browser unchanged, but the colorOperand grammar rule and Less's division-operator handling create a conflict that produces compilation errors under certain math modes.

The colorOperand Grammar Rule#

PR #4346 (merged into v4.4.0, fixing #4343) added a colorOperand parser rule to packages/less/src/less/parser/parser.js. Without it, expressions like oklch(from blue l c h) or rgb(from blue calc(r + 1) g b) failed with Could not parse call arguments or missing ')' because the single-letter channel tokens (r, g, b, l, c, h, s) were not recognized as valid operands.

The rule matches the regex /^[lchrgbs]\s+/ and returns a tree.Keyword node for the matched channel letter 1. This enables the channel identifiers to participate in Operation nodes — which is exactly what makes calc(r + 1) work — but also causes the alpha-slash conflict described below.

PR #4434 (v4.6.6, fixing #4316) tightened the regex to /^([lchrgbs])(?=\s|[,/*)]|$)/ using a lookahead, so colorOperand also fires when a channel letter is followed by /, *, ,, or ) — which was necessary to handle calc() expressions inside from expressions 2. This tightening unintentionally made the alpha-slash bug worse: b now matches even when directly followed by /, ensuring b / 0.9 is always parsed as a Less Operation.

The Alpha-Slash / Division Conflict#

CSS relative-color syntax uses / to separate color channels from the alpha value:

rgb(from var(--surface) r g b / 0.9)

Less also uses / as a division operator. After colorOperand was introduced, the parser matches b as an operand; then the / is consumed as a division operator; the full sub-expression b / 0.9 becomes a Less Operation node.

At evaluation time, Operation.eval() calls context.isMathOn(this.op) 3:

• Under --math=parens-division (the default), isMathOn('/') returns false unless inside explicit parentheses, so the Operation is emitted as-is — no error.
• Under --math=always, isMathOn('/') returns true, so Less tries to perform the division. b evaluates to a Keyword with no .operate method, hitting the throw { type: 'Operation', message: 'Operation on an invalid type' } path 4.

The existing escape hatch in Operation.eval() 5 only fires when context.math === MATH.PARENS_DIVISION, leaving --math=always without a fallback.

This is tracked in issue #4528 1, reported on 2026-09-08 against Less 4.9.1. It is an open regression.

Behavior by Mode (summary table)#

1

Analogous Fix Pattern: Math Functions (PR #4479)#

PR #4479 (v4.8.1) fixed the same class of problem for CSS math functions (sin(var(--x)), cos(var(--a)), etc.). The MathHelper was updated to return undefined — causing the function call to pass through to the browser — when its argument is an unresolvable Call node. The rgb()/hsl() color function path in color.js does not yet receive the same treatment 1.

Proposed Fix Approaches#

Two approaches have been identified 1:

1. Operation.eval() fallback — extend the pass-through escape hatch 5 to also fire when operands are unresolvable Keyword/Call nodes, regardless of math mode.
2. Color function bail-out — detect the relative-color from keyword inside rgb()/hsl() functions and return undefined early, mirroring the MathHelper approach from PR #4479.

Workarounds (until fixed)#

• Quote the value to prevent Less from parsing it:
  ~'rgb(from var(--surface) r g b / 0.9)'
• Use --math=parens-division (or omit --math=always).

1

Key Source Files#