- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 May 2019 17:19:27 +0000
- To: public-css-archive@w3.org
AFAIK, Gecko has the correct layout for the given testcase. The reason is that "baz" has already grown both rows in the ["For intrinsic minimums"](https://drafts.csswg.org/css-grid/#algo-spanning-items) step by its _minimum contribution_ (300px, making each row 150px). So in the steps where the `fit-content` clamping occurs, "For max-content maximums" and ["Distributing Extra Space Across Spanned Tracks"](https://drafts.csswg.org/css-grid/#extra-space), there is no remaining space to distribute (and `fit-content` only clamps the _limit_ anyway, not the base, and the base trumps the limit).
FYI, I asked a similar question in #209. (what [Tab refers to](https://github.com/w3c/csswg-drafts/issues/209#issuecomment-227592263) as 12.5.1 there is now [11.5 step 3.6](https://drafts.csswg.org/css-grid/#algo-spanning-items) "For max-content maximums", and 12.5.2 step 5 and 6 are now [11.5.1](https://drafts.csswg.org/css-grid/#extra-space) step 2 and 3.)
> Chromium distributes them only to the 2nd row because the 1st one doesn't have an auto or min-content min track sizing function.
As noted in #209, `fit-content` behaves as `minmax('auto', 'max-content'))` in the track sizing algorithm, with an extra clamp on the _limit_ where it's explicitly pointed out in spec.
--
GitHub Notification of comment by MatsPalmgren
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3621#issuecomment-490170973 using your GitHub account
Received on Tuesday, 7 May 2019 17:19:28 UTC