Skip to content

Bug: no-invalid-properties false positive when a custom property value contains var() inside a function #623

Open

Description

@codingstore

Environment

ESLint version: v10.14.0
@eslint/css version: 2.0.1
Node version: v26.11.1
npm version: v12.2.0
Operating System: darwin 25.6.0

Which language are you using?

stylesheet

What did you do?

Configuration
import css from "@eslint/css";

export default [
	{
		files: ["**/*.css"],
		plugins: { css },
		language: "css/css",
		rules: {
			"css/no-invalid-properties": "error",
		},
	},
];
:root {
	--rgb: 255, 255, 255;
	--color: rgba(var(--rgb), 0.5);
}

a {
	color: var(--color);
}

What did you expect to happen?

No error. --color resolves to rgba(255, 255, 255, 0.5), which is a valid <color>.

Using the same value directly is not reported:

:root {
	--rgb: 255, 255, 255;
}

a {
	color: rgba(var(--rgb), 0.5);
}

What actually happened?

7:9  error  Invalid value '255' for property 'color'. Expected <color>  css/no-invalid-properties

The rule validates color: 255, 255, 255 instead of color: rgba(255, 255, 255, 0.5). The wrapping rgba(…, 0.5) is dropped.

Link to Minimal Reproducible Example

Provided above

Participation

  • I am willing to submit a pull request for this issue.

AI acknowledgment

  • I did not use AI to generate this issue report.
  • I used AI to translate the content of this issue report.
  • I used AI to understand the codebase.
  • I used AI to generate content for this issue report and I reviewed the generated content.

Additional comments

In resolveVariable(), the custom property value is passed to parseVarFunction(), whose regex is not anchored, so rgba(var(--rgb), 0.5) is treated as if the whole value were var(--rgb) and the wrapping function is dropped.

Possibly a follow-up to #200 / #237.

Not a duplicate of #434: that one requires an unknown variable with allowUnknownVariables: true. Here all variables are defined and it reproduces with default options.

Activity

  1. eslint-github-bot commented on Nov 12, 2026

    @eslint-github-bot

    👋 Hi! This issue is being addressed in pull request #624. Thanks, @orshih6!

  2. self-assigned this
    on Nov 12, 2026
  3. added
    acceptedThere is consensus among the team that this change meets the criteria for inclusion
    on Nov 12, 2026
  4. moved this from Needs Triage to Ready to Implement in Triageon Nov 12, 2026
  5. DMartens commented on Nov 12, 2026

    @DMartens
    Contributor

    Thank you for the report, this will be fixed as part of #584.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

acceptedThere is consensus among the team that this change meets the criteria for inclusionbugSomething isn't working

Type

No type

Projects

  • Status
    Ready to Implement

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions