In ThemeUtils.resolveCssVariablesInRecord, we convert the colors to hex so Monaco and plotly are ok with the colors; however, this calls ColorUtils.normalizeCssColor which incorrectly parses oklab colors as rgba and returns something like `#0.999999999999980.4ccccccccccccc0.4ff'
I think there are a few holes in the logic here:
ColorUtils.asRgbOrRgbaString returns a computed color without checking if it is actually rgb/rgba. This is fine for hsl which resolves to rgb, but oklab colors do not compute into rgb in CSS. They resolve their internal values and you end up with oklab(L a b). 3 numbers in oklab
ColorUtils.parseRgba parses oklab(0.5 0.5 0.5) because it doesn't actually check for anything about rgb, it just looks for 3 numbers. If the value does not start with color(srgb, it just assumes anything that contains 3 or 4 numbers is RGB(A).
Further, there's a comment saying "We've already checked it's a valid color with CSS.supports". This is not always true because we depend on the caller to have verified the color. There's no verification in the method and the doc string mentions nothing about this (other than assumes already valid rgb/rgba.
Since ColorUtils.normalizeCssColor calls ColorUtils.parseRgba with values that haven't been properly verified to be rgb/rgba, and ColorUtils.parseRgba does no validation it's operating on an rgb/rgba color, ColorUtils.normalizeCssColor passes the already bad parsed value into ColorUtils.rgbaToHex8. Since oklab colors use decimals (and values can be negative), we end up passing completely invalid r/g/b values into rgbaToHex8 and creating an even more incorrect string
Depending on how correct we want to be, this will also have trouble with any other color spaces as it only checks for srgb when using color. So other color spaces with 3 numbers will be treated as rgb and expect values of 0-255.
In addition to these issues, we have separate GridColorUtils which has a bunch of utils for converting oklab/srgb colors. IMO almost all of these should be moved into ColorUtils because they are not grid specific. The only one that is is darkenForDepth which has to deal with tree colors.
In
ThemeUtils.resolveCssVariablesInRecord, we convert the colors to hex so Monaco and plotly are ok with the colors; however, this callsColorUtils.normalizeCssColorwhich incorrectly parsesoklabcolors asrgbaand returns something like `#0.999999999999980.4ccccccccccccc0.4ff'I think there are a few holes in the logic here:
ColorUtils.asRgbOrRgbaStringreturns a computed color without checking if it is actually rgb/rgba. This is fine for hsl which resolves to rgb, but oklab colors do not compute into rgb in CSS. They resolve their internal values and you end up withoklab(L a b). 3 numbers in oklabColorUtils.parseRgbaparsesoklab(0.5 0.5 0.5)because it doesn't actually check for anything about rgb, it just looks for 3 numbers. If the value does not start withcolor(srgb, it just assumes anything that contains 3 or 4 numbers is RGB(A).Further, there's a comment saying "We've already checked it's a valid color with CSS.supports". This is not always true because we depend on the caller to have verified the color. There's no verification in the method and the doc string mentions nothing about this (other than assumes already valid rgb/rgba.
Since
ColorUtils.normalizeCssColorcallsColorUtils.parseRgbawith values that haven't been properly verified to be rgb/rgba, andColorUtils.parseRgbadoes no validation it's operating on an rgb/rgba color,ColorUtils.normalizeCssColorpasses the already bad parsed value intoColorUtils.rgbaToHex8. Since oklab colors use decimals (and values can be negative), we end up passing completely invalid r/g/b values intorgbaToHex8and creating an even more incorrect stringDepending on how correct we want to be, this will also have trouble with any other color spaces as it only checks for srgb when using color. So other color spaces with 3 numbers will be treated as rgb and expect values of 0-255.
In addition to these issues, we have separate
GridColorUtilswhich has a bunch of utils for converting oklab/srgb colors. IMO almost all of these should be moved intoColorUtilsbecause they are not grid specific. The only one that is isdarkenForDepthwhich has to deal with tree colors.