Re: [csswg-drafts] [css-values] Make it explicit that min(), max(), clamp() require arguments to have the same type (#7496)

@Loirooriol , @tabatkins, forgive me for interjecting this into an Editorial story, but it is related and, based on the umpteen other tangentially-related issues I've read, you two are apparently  some of the most-informed people on Earth regarding this topic, specifically.

I've been combing through the spec trying to work out why one cannot get a `<number>` type result from a `clamp()`. I can see that this is the case, to be sure, but not necessarily _why_ it should be. As Loirooriol states above, this is clearly the intention, so i assume there's some deep-dark gotcha endemic to the problem, but nothing I've found says what it IS. That is to say:

Presupposing I have a couple simple calculations I'm performing... say:
```
/* 0px or 1px, based on if my viewport's width > 1024px */
    --pixelResult : clamp( 0px, calc( 100vw - 1024px ), 1px );  

/* 0% or 100%, based on if --pixelResult != 0 */ 
    --prcntResult : clamp( 0%, calc( var(--pixelResult) * 9999 ), 100% ); 
```
...both by necessity result in a `<length>` (based, I'm assuming, on the [serialization process](https://drafts.csswg.org/css-values-4/#calc-serialize) the calculation undergoes, and the necessity of a cohesive value, being the result of the `min`/`max` `clamp` is [functionally syntactic sugar for](https://drafts.csswg.org/css-values-4/#funcdef-clamp)?).

But my question amounts to: is there a reason the specification avoids the ability to get a <number> result (other than, of course, the syntax not currently supporting same, natch)? I'm sure you can see where I'm going with this, but, is there any particular reason one SHOULDN'T be able to get what amounts to a boolean test out of the `calc`/`clamp` "test" above? The example is contrived, I know, but I've no doubt you follow me here: there's plainly a comparative test being performed, if only a mathematical computation, but if the user is specifying the over/under values anyway, why _not_ permit `hidden`/`visible` or `relative`/`absolute` as the result? Even just a <number> 0 / 1 would be useful (I cannot apply `--prcntResult` in an `opacity` or a `rgba()`, as a for-instance).

I grasp this particular scenario would be better resolved with media queries - again: contrived example - but it seems like it would offer a great deal of flexibility when dealing with two elements whose dimensional characteristics change during runtime (deriving a UI scale factor based on the largest entry in a word cloud, for an off-the head example, for instance).

Again, please forgive my using this as the venue for asking this; it's literally simply the first related topic where you two specifically were the only conversants. I'm just now starting to dabble into the specification sector; if there is a more appropriate place to inquire/discuss/advocate after such things (I'm certain there is), and if you'd be so kind as to point me that way, I'll delete this comment and get out of your hair.

In any event, thank you both, truly, for all you both do. It's people like you that are literally carrying the web's forward progress on your backs. I've nothing but mad respect for you both.

-- 
GitHub Notification of comment by NerdyDeedsLLC
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7496#issuecomment-1229160403 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 27 August 2022 09:43:29 UTC