Custom properties inside builtin functions like `rgba()` throw error

[MikeKovarik]

Syntax of the content of CSS custom properties is very permissive but that causes problems when using such properties inside builtin functions like rgba()

Example:
My project allows user to define accent color on which the whole app UI and various custom components is based. And I am using rgb format because of the need to fade in certain places and CSS does not provide anything like fade(@color, 50%) in less. That way i can do rgba( var(--color), 0.5 ). This works in Chrome and is supported by the standart. However less throws the following error error evaluation function 'rgba': color functions take numbers as parameters.

Example code:

:root {
	--color-accent: 169,57,255;
}
button:hover {
	background-color: rgba(var(--color-accent), 0.2);
	color: rgb(var(--color-accent));
}

Note: This is a drop-in library and i don't want to force users to add another build step into their workflow only to build my less library with their colors. That's why i'm using the new and shiny custom properties (and also because of its scoping capability).

BTW: Is there some temporary workaround that'd skip such strict handling and build it anyway? It's not like I'm missing a bracket in a nested rules.

[seven-phases-max]

Just escape.

---

I put "Feature Request" label since it definitely becomes a problem when the custom properties are in TR. It's easy to fix by disabling any error detection for CSS functions args (though it's quite sad as it kills an important part of the language - i.e. we'll never find a error anymore until debug in a browser).

[matthew-dean]

Custom properties have support across all browsers except IE11. They'll probably hit mainstream within the next year, so I think support should be implemented soon.

Less, AFAIK, also doesn't have tests for the extremely permissive nature of custom property values. They can contain pretty much anything, even semi-colons, as long as they're not top-level tokens (not contained in bracket or curly-brace pairs). See: https://www.w3.org/TR/css-variables/#syntax

[seven-phases-max]

Since this change requires an n-of-args checking anyway (to keep at least some error validation within the functions), it's also assumed that the newer rgba implementation also supports the two argument form for ordinal color values, e.g.:

rgba(var(--some), .42); // -> rgba(var(--some), .42)
rgba(#010101, .42); // -> rgba(1, 1, 1, .42)