[css-values] Re-adding min() and max()?

[LeaVerou]

Perhaps now that Values 3 has gone to CR it's time to reconsider adding min() and max() back into Values 4?

Authors are doing extremely weird hacks with calc() to emulate them in font-size and line-height, which they call "CSS locks". If you google CSS locks you will see how widespread these hacks are becoming, indicating a clear author need.

Furthermore, as CSS variables become more widely used, the need for min() and max() will become even greater. I recall some of the issues that made us drop them 6 years ago can now be solved with the invalid at computed value time concept that Variables introduced.

[Crissov]

So, for “locks”,

selector {
  property: /* $min_value ≤ */ $fallback_value /* ≤ $max_value = $min_value + $max_increment */;
}
@media (min-width: $min_vw) and (max-width: $max_vw) {
  selector {
    property: calc( $min_value + $max_increment *   (100vw - $min_vw) 
                //*                               ———————————————————  */
                                                  ($max_vw - $min_vw)  );
  }
}
@media (max-width: $min_vw) {
  selector {
    property: calc( $min_value + 0 );
  }
}
@media (min-width: $max_vw) {
  selector {
    property: calc( $min_value + $max_increment /* = $max_value */ );
  }
}

would become

selector {
  property: /* $min_value ≤ */ $fallback_value /* ≤ $max_value = $min_value + $max_increment */;
  property: calc( $min_value + $max_increment * min(  (100vw - $min_vw) 
              //*                                   ———————————————————     */
                                                    ($max_vw - $min_vw), 1) );
}

right?

I wonder if authors would also find good use for mid()dle/avg(), med()ian, mod()e etc.

[MadeByMike]

I proposed a map() function that allows for min and max sizes as well as easing and interpolation of more than just length units: #581

I think this would be a much more versatile approach, especially with things like variable type, where min() and max() might not work.

[MadeByMike]

People have shared with me examples of how min() and max() functions in CSS might work in addition to a map() function. So to clarify, I don't think it needs to be one or the other.

Since calc() allows some min and max functionality (although not with whole numbers) It might be useful to consider other implementations of min and max including returning the min and max value of a set e.g. max(14px, 1em, 1rem, 3vw).

[LeaVerou]

It's generally good API design practice to have shortcuts for commonly needed things, otherwise you end up with clunky, verbose APIs that are a pain to use for anything. I will not discuss whether what you're proposing is a good idea or not here, partly because I haven't thought about it much. However, even if it is, using map() to specify the min of two values results in extremely weird and convoluted code. Power is good, as long as it stays out of your way when you don't need it.

[Crissov]

I wonder whether min() and max() would be the best notation, however, especially if these operations were only available within calc(). I know it’s unusual and incompatible with programming languages (which need logic operators and, unlike CSS, have a boolean data type), but maybe < and > (or << and >>) could be used as operators instead.

{
min(100px 10em 10vw)      calc(min(100px 10em 10vw));
min(100px, 10em, 10vw)    calc(min(100px, 10em, 10vw));
100px < 10em < 10vw       calc(100px < 10em < 10vw);
100px << 10em << 10vw     calc(100px << 10em << 10vw);

max(100px 10em 10vw)      calc(max(100px 10em 10vw));
max(100px, 10em, 10vw)    calc(max(100px, 10em, 10vw));
100px > 10em > 10vw       calc(100px > 10em > 10vw);
100px >> 10em >> 10vw     calc(100px >> 10em >> 10vw);
}

This works well for minimum and maximum where you can compare one pair after the other – CSS has only + not sum() despite grammar issues with the former. It would be more complicated to spec for other statistical functions but straightforward for some other operations, also the character repertoire (i.e. Latin 0 punctuation marks) is limited:

{
calc(a | b);	/* median */
calc(a = b);	/* arithmetic mean, average */
calc(a # b);	/* either count or mode (work) or geometric mean (doesn’t work) */
calc(a ~ b);	/* round $a to an integer multiple of $b */
calc(a _ b);	/* floor, round down $a to an integer multiple of $b */
calc(a ` b);	/* ceiling, round up $a to an integer multiple of $b */
calc(a ^ b);	/* $a to the power of $b */
calc(a % b);	/* $a modulo $b, or $a integer-divided by $b, or remainder of $a/$b */
calc(a : b);	/* one of the other from the line above */
/* … */
}

[LeaVerou]

I believe we can't add angle brackets for some syntax reason, which is why we used min- and max- in media queries. But even if we could, your proposed syntax does not look more clear to me at all, and I don't understand why it would only be usable within calc(), there's no reason to not allow it bare. Furthermore, I don't think the other operators are more clear either, both to non-programmers and programmers alike, for different reasons. We don't need more ASCII art in CSS. And the modulo operator being % is a huge mistake IMO, since % has a clearly defined role in language, which is completely different than modulo.

[cvrebert]

I believe we can't add angle brackets for some syntax reason, which is why we used min- and max- in media queries.

Erm, MQ4 uses angle brackets: https://drafts.csswg.org/mediaqueries-4/#mq-range-context

[Crissov]

The reason for avoidance of < (in the past) was compatibility, not really syntax, as far as I remember. I don’t fancy % as a binary operator either, but it has precedent elsewhere.

The advantages of > over max() are really the same as for + vs. sum(), except that plus is much better established elsewhere. Semantically, > continues with the larger of the adjacent terms, whereas max() selects the largest out of a list. I prefer the latter in programming languages and spreadsheet applications, but, unlike those, CSS has only scalars to deal with – no vectors, ranges, arrays or objects (except perhaps for <<color>> eventually). We don’t need more JS notation in CSS.

[frivoal]

a > b does not read like the larger of a and b to me, but true if a is larger than b, false otherwise. Not just because that's what it means in many programing languages, but because that's what it means in math. I'm not favorable to this notation at all.

[Crissov]

In mathematics, though, < and > are usually only used as relation symbols and not as operators. Outside MQ, CSS does not use logic expressions, unlike pretty much every programming language.

Pairing the angle brackets, i.e. >min< and <max>, also kinda works for me.

{
    max(a b c)    calc(max(a b c))
    <a b c>       calc(<a b c>)
    a > b > c     calc(a > b > c)

    min(a b c)    calc(min(a b c))
    >a b c<       calc(>a b c<)
    a < b < c     calc(a < b < c)

    abs(a)        calc(abs(a))
    |a|           calc(|a|)

    round(a, b)   calc(round(a, b))
    [a]b          calc([a]b)
    [a]~b         calc([a]~b)
    a ~ b         calc(a ~ b)

    floor(a)      calc(floor(a))          ⌊a⌋
    [a]_          calc([a]_)
    _a_           calc(_a_)
    (a _)         calc(a _)

    ceil(a)       calc(ceil(a))           ⌈a⌉
    [a]`          calc([a]`)
    [a]^          calc([a]^)
    `a`           calc(`a`)
    ^a^           calc(^a^)
    (a `)         calc(a `)
}

[MatsPalmgren]

Please use function syntax. Readability is much more important than saving a few key strokes.

[Crissov]

Readability is my primary goal, too! It’s so easy to get lost in the parentheses of nested functions.

[frivoal]

To pretty much everybody who has ever seen that symbol, a > b means "a is larger than b" not "the larger of a and b", so I strongly object to giving it that meaning.

My objection against <a b> and >a b< is less strong, as there is no existing universally accepted meaning to it. I still don't like them though. max(a b) is much more guessable, much more googlable, easier to search in a a file that mixes markup and css...

[Crissov]

It's a bit like default/fallback values in Lua etc.: Takes some time to get used to, but makes sense.

Anyway, I'm not feeling strongly about this, just wanted to provide some thinking outside the box.