Re: [csswg-drafts] [css-values] Make min and max value optional in `clamp()` (#9713)

The CSS Working Group just discussed ``[css-values] Make min and max value optional in `clamp()` ``, and agreed to the following:

* `RESOLVED: Add 'none' keyword for upper/lower bounds of clamp().`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> lea: the reason we introduced clamp() is that clamping with min() / max() is counter-intuitive, upper bound means min() and lower bound you need max()<br>
&lt;emilio> ... however author still need min() / max() when only have a lower bound or upper bound<br>
&lt;emilio> ... I found myself doing clamp(.., infinity) or such thing<br>
&lt;fantasai> ... suggestion in issue is to add a 'none' keyword<br>
&lt;emilio> ... so we discussed it in the issue, and it seemed like 'none' was straight-forward<br>
&lt;emilio> ... I even found author infographics about how confusing this is<br>
&lt;TabAtkins> +1 to this, as I said in the thread<br>
&lt;emilio> q+<br>
&lt;oriol> q+<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: what's the reason for 'none' vs omission<br>
&lt;fantasai> fantasai: beause there's commas involved<br>
&lt;fantasai> TabAtkins: having an empty spot indicated only by presence of commas<br>
&lt;florian> q+<br>
&lt;fantasai> TabAtkins: is extremely awkward (and also violates comma elison rules)<br>
&lt;dholbert> scribe+<br>
&lt;dholbert> emilio (IRC): I was thinking you could clamp with 2 values<br>
&lt;dholbert> TabAtkins (IRC): which is which, upper vs lower<br>
&lt;astearns> ack oriol<br>
&lt;dholbert> emilio (IRC): then 'none' makes sense<br>
&lt;emilio> oriol: I kinda disagree with min() / max() being workarounds<br>
&lt;emilio> ... they mathematically are the same, but I agree there's some confusion<br>
&lt;emilio> ... not sure if this will completely solve it<br>
&lt;emilio> ... they may not realize that clamp(none) can help it<br>
&lt;emilio> ... this seems a pretty straight-forward generalization so seems fine, tho<br>
&lt;emilio> lea: when I said workaround it's a UX argument, not a mathematical argument<br>
&lt;astearns> ack florian<br>
&lt;emilio> ... when something is used for it's non-primary purpose it's a workaround<br>
&lt;lea> q+<br>
&lt;fantasai> florian: from utility point of view, setting both lower and upper bound to none is useless, but should we still allow it in the syntax?<br>
&lt;emilio> florian: setting both to none is useless<br>
&lt;lea> q-<br>
&lt;fantasai> TabAtkins: keep them both, because might be in a variable<br>
&lt;emilio> ... but should we keep them?<br>
&lt;fantasai> astearns: Seems we're all in violent agreement here<br>
&lt;fantasai> RESOLVED: Add 'none' keyword for upper/lower bounds of clamp().<br>
&lt;emilio> PROPOSAL: Allow none as firs or last arguments for clamp()<br>
&lt;lea> 🎉<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9713#issuecomment-1944449961 using your GitHub account


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

Received on Wednesday, 14 February 2024 19:22:42 UTC