- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jul 2020 22:57:42 +0000
- To: public-css-archive@w3.org
> because we don't want it to clamp the minimum size to a max of 100px. Sure, we don't want to clamp to a max of 100px when distributing min contributions, because min wins over max. But we do want to clamp when distributing max contributions. Otherwise `fit-content(100px)` would behave exactly like `minmax(auto, max-content)`! So, imagine - You have two tracks: `fit-content(100px)` and `0px`. - The grid has a definite size (not sizing under a min/max-content constraint) - There is a grid item spanning both tracks. The item has a minimum contribution of 0, so the base size of the tracks stay at 0. But the item has a max-content contribution of 300px, and we distribute that into `fit-content(100px)`. After you change, the `fit-content(100px)` gets all the 300px into its growth limit. So the `100px` argument is totally ignored. Here it should definitely be clamped. Another case: - You have two tracks: `fit-content(100px)` and `max-content`. - The grid has a definite size (not sizing under a min/max-content constraint) - There is a grid item spanning both tracks. The item has a minimum contribution of 300px, and we distribute that among the base sizes of the tracks. With the current spec, both tracks will end up with a base limit of 150px (since currently they have an infinite growth limit). What I'm saying is that the `fit-content(100px)` track should get 100px, and the remaining 200px should go to the `max-content` track. But of course, if there was no other track which could take these 200px, they definitely should end up going to the `fit-content(100px)` track, because min wins over max. I'm not arguing against that. -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4549#issuecomment-662738127 using your GitHub account
Received on Wednesday, 22 July 2020 22:57:44 UTC