Per w3c/csswg-drafts#9484, it's possible for color space conversion to produce a color that's outside the gamut of the space it's represented in even when that space is clamped at parsed-value time. This means that color.to-space(color(xyz 1 1 1), lab) represents a valid and meaningful CSS color value in the Lab color space that cannot be represented with the lab() syntax because its lightness is 100.12.

To handle edge cases like this, I think we should add a special case to the color serialization spec that checks whether a non-legacy color has a channel value outside its clamped range and, if so, emits an XYZ color (which has no range gamut limitations whatsoever) that's converted to the given color space via color-mix(). For example, color.to-space(color(xyz 1 1 1), lab) would be emitted as color-mix(in lab, color(xyz-d65 1 1 1) 100%, black). This is a little silly in that Sass doesn't support the native CSS color-mix() function, but it's the only way I know of to ensure that the colors we emit represent the same colors as Sass's notion.

@jamesnw This probably means we should also allow out-of-range lightness values for Lab/OKLab/LCH/OKLCH in the JS API and the embedded protocol as well.