Re: [csswg-drafts] [css-values] Add clamp()?

The Working Group just discussed `clamp()`, and agreed to the following:

* `RESOLVED: Add clamp(min,mid,max) with min winning over max`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic: clamp()<br>
&lt;fantasai> TabAtkins: Proposal for a clamp function to be added<br>
&lt;fantasai> TabAtkins: Equivalent to using min &amp; max in combination<br>
&lt;fantasai> TabAtkins: but it's pretty common to do both<br>
&lt;fantasai> TabAtkins: And nested functions for this are a bit confusing to read<br>
&lt;fantasai> TabAtkins: Variations are might want max to win, which it doesn't for CSS in general<br>
&lt;fantasai> fantasai: Now I understand why astearns but the minmax() issue from Grid on the agenda<br>
&lt;fantasai> fantasai: We might want to look at that before resolving<br>
&lt;dbaron> fantasai: there are 2 independent issues open on grid, affecting minmax()<br>
&lt;dbaron> fantasai: first is an issue where the request was to have 'fr's in the min position<br>
&lt;dbaron> fantasai: somebody wanted to have 1fr but cap at 250px... space then goes elsewhere<br>
&lt;dbaron> fantasai: seemed like you might want to control the min on that fr, so you might want minmax() to take 3 arguments<br>
&lt;dbaron> fantasai: the min, the goal fr, and the max<br>
&lt;dbaron> fantasai: other issue on minmax() was that when we were working on grid level 1, somebody said that min winning over max really bothered them, with a valid use case.<br>
&lt;dbaron> fantasai: there are also use cases for min winning, and that's generally how CSS works, so we stuck withit for level 1, but refiled against grid level 2<br>
&lt;dbaron> fantasai: both of these issues are ready for working group discussion<br>
&lt;dbaron> fantasai: syntax for clamp() ties into these same requests<br>
&lt;dbaron> fantasai: if we extend minmax() to have 3 arguments to handle the 'fr' case where it makes sense to have both a min and a max, then that's the syntax we should use<br>
&lt;dbaron> fantasai: alternatively, if you want the 3 argument version then you have to change the name to clamp()<br>
&lt;dbaron> fantasai: one advantage of the minmax() name which Microsoft people came up with is that it's really clear that the min comes first and the max comes last<br>
&lt;dbaron> fantasai: a  clamp() function doesn't have that property<br>
&lt;dbaron> fantasai: what's currently in the proposal for clamp() is that the order is max-min, the first one still wins, maybe that's a reasonable proposal for one where max wins<br>
&lt;dbaron> fantasai: for grid ... ???<br>
&lt;dbaron> fantasai: if we're going to try to solve them we should try to be consistent<br>
&lt;fantasai> TabAtkins: i think only thing that directly affects this is ordering argument<br>
&lt;fantasai> TabAtkins: ordering should match my proposal here<br>
&lt;fantasai> TabAtkins: I don't think anything else needs to care for base proposal<br>
&lt;fantasai> fantasai: But also I think we should use the same name, mimax() -- and maxmin() for the max-wins case<br>
&lt;fantasai> TabAtkins: minmax() doens't resolve to a number<br>
&lt;dbaron> TabAtkins: minmax() in grid is not a clamping function.  It's not a mathematical function; it's an instruction to the layout algorithm.<br>
&lt;dbaron> fantasai: minmax() with 2 arguments is a range, minmax() with 3 arguments resolves to 1 of the arguments<br>
&lt;dbaron> TabAtkins: not until layout time<br>
&lt;dbaron> fantasai: percentages in here also don't resolve until layout time<br>
&lt;dbaron> TabAtkins: 3 argument is similar to the 2 argument, still specifying a range<br>
&lt;dbaron> fantasai: what?<br>
&lt;dbaron> TabAtkins: the 3 argument version in grid will still have similar behavior, a command deeply integrated into the layout function, not something usable anywhere that can take various values<br>
&lt;dbaron> TabAtkins: and the value space of its arguments is dramatically different from what we want to allow<br>
&lt;dbaron> TabAtkins: semantically similar but very different in the details and we shouldn't be trying to reuse the name<br>
&lt;dbaron> Rossen: how do you propose to have contain work with variables?<br>
&lt;dbaron> TabAtkins: clamp?  It's just a shorthand for the min() and max() functions that just implements clamping in the standard CSS fashion.<br>
&lt;TabAtkins> s/contain/clamp()/<br>
&lt;fantasai> astearns: If we do have separate minmax() with three values and clamp() with three values, should have same parameter order at least<br>
&lt;dbaron> astearns: if we have separate minmax() with 3 values and clamp() functions I think it makes sense to have the same parameter order at least.<br>
&lt;fantasai> TabAtkins: Yes, I agree. Already have that in both proposals<br>
&lt;fantasai> astearns: Are we coming to a resolution here, to add a clamp() function with min, mid, max?<br>
&lt;fantasai> astearns: Are you convinced to use clamp(), fantasai?<br>
&lt;fantasai> fantasai: I'm not sure yet, but not objecting 'cuz not sure<br>
&lt;fantasai> RESOLVED: Add clamp(min,mid,max) with min winning over max<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/2519<br>
</details>


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

Received on Wednesday, 9 May 2018 16:48:48 UTC