sRGB color notations converting to hex with option disabled

[keithjgrant]

trafficstars

The documentation states, "By default Lightning CSS does not perform any transpilation of CSS syntax for older browsers. This means that if you write your code using modern syntax or without vendor prefixes, that’s what Lightning CSS will output."

However, if I leave target browsers list empty and don't include any features, some colors are getting converted to hex notation. This happens for rgb(), hsl(), and hwb() colors, but not for newer wide-gamut notations like oklch() and oklab().

Expected result: colors should be left as authored in the final output

Actual result: Most color notations are being converted to hex

Example in online playground

[devongovett]

The purpose of this is not to transpile for older browsers but to minify the size. Hex colors are semantically equivalent to any other RGB notation, whereas something like oklch can represent colors that RGB cannot. That's why those colors are preserved and RGB colors are minified using the shortest notation possible. So this is is a feature not a bug. Any reason you need the longhand notation instead of hex?

[keithjgrant]

During development, I want to be able to play with those values in the browser DevTools, so it would be great if they were the same format as authored. (I primarily use Firefox, which doesn't yet support conversion to oklch in DevTools)

Ideally, I would want them to convert to the shorter syntax when minification is enabled, but not when it is turned off (though I understand this is probably handled in a different part of the pipeline than minification)

[keithjgrant]

On a related note, in some cases it converts oklch to oklab despite oklab being markedly more verbose:

--slate-1: oklch(98% 0.006 251deg);

is getting converted (inside a feature query) to:

--slate-1: lab(97.6739% -.628799 -2.15917);

This happens whether minification is enabled or not.

Example