[css-color] Support using "inherit" in color-mix()

[fabiospampinato]

CSS Color 5 added the color-mix function, but it looks like it doesn't allow for mixing inherit. It'd be pretty powerful to enable support for that in some properties, so I think it should be added.

[svgeesus]

How would that work?

p {  
    border-color: color-mix(in oklab, inherit 70%, black);
}

the inherited value of what property? Here it could reasonably be inferred, but

p {  
    --foo: color-mix(in oklab, inherit 70%, black);
}

[fabiospampinato]

I'm thinking it would only work when it could work.

So for example when using it with border-color, color, background-color etc. inherit would point to the value of that same property on the parent.

And it would simply not be supported for other arbitrary properties because it wouldn't make sense in that context.

[Loirooriol]

This can be covered by #2864 (but for now it may be restricted to custom properties).

Worth noting that border-color is a shorthand, so something like this seems safer:

    border-top-color: color-mix(in oklab, inherit(border-top-color) 70%, black);
    border-right-color: color-mix(in oklab, inherit(border-right-color) 70%, black);
    border-bottom-color: color-mix(in oklab, inherit(border-bottom-color) 70%, black);
    border-left-color: color-mix(in oklab, inherit(border-left-color) 70%, black);

Doing the expansion automatically seems tricky. I guess the process would be like:

1. Treat inherit() as a <color>
2. Do longhand expansion normally
3. Each longhand receiving inherit() resolves it to that same longhand (not the shorthand).

but what if the shorthand has longhands that don't compute to a <color>? Like

    border: 5px solid color-mix(in oklab, inherit() 70%, black);

some longhands like border-top-width compute to a length instead of to a color. Of course using a length there wouldn't be valid syntax, but in general we could get ambiguous situations. So how do we know inherit() should be treated as a <color>?

[fabiospampinato]

some longhands like border-top-width compute to a length instead of to a color. Of course using a length there wouldn't be valid syntax, but in general we could get ambiguous situations. So how do we know inherit() should be treated as a ?

I'm thinking inherit() could be wired up with all the situations where it would work unambiguously manually. So for example:

• border-top-color: it gets the border-top-color on the parent.
• border -> it gets the border-color, if there isn't one transparent or something else could be returned (the average of all the colors on all sides?).
• border-top-width: this property is not associated with a color, so using inherit() here would simply return some fallback value I suppose.

Basically I'm thinking a logic that should work would be this:

• Is the user calling inherit() (or simply inherit) inside color-mix? If so we are going to get a color. If the user called it for a property where it makes sense it will get the obvious color value for that property on the parent, otherwise something like transparent, if not even a non-color to break the color-mix call, could be returned.

[bleper]

This won't always work, as border-color and its derivations accept images, and there are properties whose values are lists or those that accept multiple colors.

[fabiospampinato]

Maybe inherit could return transparent (or some other fallback value) in those cases? Like is there something better that it could do?

[bleper]

I think this is bad for the consistency of the language, it should give an initial value. There is also a suggestion to add a fallback to inherit() to align it with var() and env().

[svgeesus]

Indeed this seems like a better approach, as @Loirooriol suggested

• [css-values-5] inherit() function: like var() for parent value, for any property #2864