Re: [csswg-drafts] [css-grid] minmax(auto, min-content) under a max-content constraint (#3565)

The CSS Working Group just discussed `minmax(auto,min-content) under a max-content constraint`.

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: minmax(auto,min-content) under a max-content constraint<br>
&lt;heycam> github: https://github.com/w3c/csswg-drafts/issues/3565<br>
&lt;heycam> Rossen: Elika or Mats or Loriel on the call?<br>
&lt;heycam> s/Loriel/Oriel/<br>
&lt;heycam> oriol: the issue is that when you have track sizing with minmax(auto,min-content), and the grid container is being sized under a max-content constraint<br>
&lt;heycam> ... the spec says that the auto minimum becomes the max-content contribution of the item<br>
&lt;heycam> ... however this is just when sizing the grid container. once you know its size, which will be determined with the max-content contribution of the item, then you layout again for real, using this size<br>
&lt;heycam> ... but this time since it's not being sizes under the max-content constraint, since you already know the size, then the auto minimum just reduces the minimum contribution<br>
&lt;heycam> ... which is usually like the min-content contribution<br>
&lt;heycam> ... then since the max-sizing function of the track is also min-content, then the grid item wouldn't grow<br>
&lt;heycam> ... but the grid container would be bigger than the track<br>
&lt;heycam> ... the result seemed a bit strange<br>
&lt;heycam> ... instead Chrome and Edge seem to clamp the auto minimum in this max-content constraint, which was behaving as a max-content contribution,<br>
&lt;heycam> [missed]<br>
&lt;heycam> ... then fantasai did some edits<br>
&lt;heycam> ... and asked for review<br>
&lt;heycam> Rossen: also rehashing some of the thread<br>
&lt;heycam> ... Mats from Gecko also has an explanation of what Gecko does, and according to him, the behavior Firefox currently implements is per spec<br>
&lt;heycam> Rossen: what I'm wondering is if there is a concrete proposal for change here<br>
&lt;heycam> oriol: fantasai already did the edits<br>
&lt;heycam> ... Firefox was following the spec before the edits<br>
&lt;heycam> ... then I think this would just be for approving the edits fantasai already did<br>
&lt;florian> https://github.com/w3c/csswg-drafts/commit/ea7028dfe4d5d8b8430b9e9622de3ecbc418adad<br>
&lt;florian> https://github.com/w3c/csswg-drafts/commit/a3091ab46f393c5b50a5a9dcce558214041ea8d1<br>
&lt;heycam> fantasai: there was another commit<br>
&lt;heycam> florian: the second link there is the main commit, the first is a fixup to that<br>
&lt;heycam> florian: this matches what Chrome and Edge do but not Firefox, right?<br>
&lt;heycam> Rossen: yes<br>
&lt;heycam> florian: is Mozilla ok with that?<br>
&lt;heycam> jensimmons: I am here but can't say about this issue<br>
&lt;heycam> fantasai: basically what we're trying to do here is not exceed the growth limit when we are sizing under a max-content constraint<br>
&lt;heycam> ... the spec as it is right now says to size hte max content when we're calculating the minimum contribution<br>
&lt;heycam> ... and if the growth limit is a fixed number it's clamped by that, but if it's a keyword it's not clamped by that<br>
&lt;heycam> ... in  a lot of cases it doesn't matter<br>
&lt;heycam> ... but if your growth limit is min-content you probably want to limit yourself to that<br>
&lt;heycam> ... otherwise you contribute more space then you end up using in the end<br>
&lt;heycam> Rossen: we have 3 impls shipping. Gecko is the only one that will have to change here, even though they are implementing the previously specced behavior<br>
&lt;heycam> ... we can call for objections and resolve on accepting the changes, and then work through additional issues being raised by Gecko, or give this another week to get Mats' perspective<br>
&lt;heycam> Rossen: implementation wise, the fact that this is implemented already in 3 engines out of 4 we have a proof of existence that it's implementable<br>
&lt;florian> heycam: in mats's comment, did he indicate whether he was happy with the chage?<br>
&lt;florian> s/chage/change/<br>
&lt;heycam> jensimmons: I think that what authors will want is what Chrome/Edge implement right now<br>
&lt;heycam> ... so it would make sense to do what authors are going to need/want out of this<br>
&lt;heycam> florian: in Mats' comment he is somewhat arguing for the old logic makes sense<br>
&lt;heycam> ... but also we could cap like in Chrome if it's desirable<br>
&lt;heycam> Rossen: I don't think he's arguing implementation complexity<br>
&lt;heycam> florian: I think the most interesting part of this comment, is whatever you decide, please make sure it makes sense when span is more than 1<br>
&lt;heycam> ... and there is a mix of min and max content sizing constraints<br>
&lt;florian> "Whatever you decide, please make sure it makes sense also when span > 1 and when there's a mix of fixed and `min-content` max-sizing tracks."<br>
&lt;heycam> fantasai: I should go through a double check this holds true with my changes<br>
&lt;heycam> ... or if additional edits are needed<br>
&lt;heycam> Rossen: so general consensus on accepting this edit. followups after Mats comments would be good.<br>
&lt;jensimmons> +1<br>
&lt;heycam> ... otherwise we could easily resolve this next week on the call. does that sound reasonable?<br>
&lt;heycam> florian: yes<br>
</details>


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

Received on Thursday, 7 February 2019 00:19:11 UTC