It can't be used as a lower-level syntax, unfortunately.

We have to be able to tell, at parse-time, what the type of the function is, and do so without clever grammar manipulation (because browsers don't have powerful-enough grammar handling tools right now, and have no plans to add such). That is, any attempt to define their parse-time validity as something like "sub it and see if it works" is a no-go. I tried that with var() fallback values and had to back it out, because when you had two or more var() functions they can interact in complex ways and you have exponential checking possibilities.

The existing mixing functions are fine in this regard - math functions define precisely how to determine their type, cross-fade() is an <image>, color-mix() is a <color>.

This is also important because we have to know how to interpolate the values; a bare "red" as one of the values might be a color keyword and want to be interpolated "as <color>", but we can't know that for certain without the clever grammar manipulation (putting it in, parsing the property, and seeing what component it gets assigned to).

Whole-property values are fine, because their interpolation type is just "the property it's being used in".

So, any low-level interpolation function must be type-specific and clearly advertise its type at parse-time in some manner.

So if I get it right,

• mix() is just top-level, but accepts arbitrary values that can be used in that property, and interpolates according to the property.
  For example, aspect-ratio: mix(50%, 1, 9) is 3.
• interp() or something from [css-values] Add easing function interpolation to calc #6697 is lower-level, but only interpolates calculation values, and interpolates according to the type of the calculation.
  For example, aspect-ratio: calc(interp(50%, 1, 9)) is 5.

With both of them, I guess most usecases will be covered.

Two alternatives which would allow it to be used as a lower-level syntax despite browser implementors' opposition to requiring type inference:

1. Type (i.e. treat during parsing) the new function (mix, interpolate or whatever) as returning a dimensionless number.
2. Add an (optional, with dimensionless by default?) argument indicating the type (e.g. length, taken from CSS grammar). Percentages are always also valid (so e.g. no need to specify (or even allow) length-percentage).

I prefer (2) (it even subsumes (1) if the type is optional), but probably a very common case would be to express a dimensionless number and multiply it by a dimensioned constant (likely 1).

Treating is as a number for grammar purposes wouldn't be useful; it would just be invalid in any place you wanted to use it that wasn't a number.

We could potentially add a type explicitly; the problem is that it only actually gets us a few more types of things, really.

If we have a separate interpolation function for top-level values vs. component values like 5em, I think their syntax should be as identical as possible and they just differ in name.

And also, the names should be coordinated, e.g. share the ''-mix'' suffix or whatever. So mabye

• ''mix()'' vs ''calc-mix()'', or
• ''value-mix()'' vs ''mix()'' (since calc mix is likely the more common), or
• some other pairing

Yeah agreed; specifically, the numeric one should look as close to color-mix() as possible, as the most clear parallel.

I'm fine with the property-mixer being named mix(); it's not obvious to me, at least, which will end up most popular, and the typed mixers already have a tradition (n==2, but still) of more specific names (cross-fade(), color-mix()).

What are the use cases for calc-mix() or whatever it ends up being called? Is it just a shorthand for calc(a * p + b * (1 - p))? Or would it also accept keywords like auto, min-height etc?
I’m a little concerned that we're adding multiple syntaxes authors need to be able to decide between, doing very similar things, for parsing reasons that are really difficult to explain to authors.

@LeaVerou calc-mix() definitely should not be introducing new functionality to calc() so yes, it's a shorthand. But only as long as the only possible progress argument is PERCENTAGE, and we're planning to add other things than PERCENTAGE constants there.

Yes, it's a shorthand, but that doesn't make it unreasonable. You have a mixing function per distinct "type" of mixable value.

But only as long as the only possible progress argument is PERCENTAGE, and we're planning to add other things than PERCENTAGE constants there.

I'm not sure what you mean by this, @fantasai?

The CSS Working Group just discussed [css-values-4] Validity of generic interpolation function mix(), and agreed to the following:

• RESOLVED: The mix interpolation function will only be used for top-level values with various discussed caveats. mix is the name of the top level interpolation

I'm not sure what you mean by this, @fantasai?

@tabatkins We're planning to add things that don't parse as a percentage, they output a percentage. So the syntax space for the percentage of the mix() function is going to get way more complicated with things that aren't going to be allowed inside calc().

I'm still not sure what you mean - it sounds like you're saying that you want to allow functions that return a percentage, but that would be compatible with having the argument be <percentage>, so I'm not sure what the issue is. Can you provide an example?