- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Fri, 10 May 2019 00:58:08 +0000
- To: public-css-archive@w3.org
> So I guess you are saying that when multiple bullets apply, we should consider the union? With the "if there are no such tracks, then all affected tracks" happening at the end after doing the union. Yes, given that the affected tracks may contain tracks in both these categories, it doesn't make much sense to apply the "if there are no such tracks, then all affected tracks" to each bullet separately. > When distributing "For intrinsic minimums", Chromium only applies the first bullet, i.e. only tracks matching `HasAutoOrMinContentMinTrackBreadthAndIntrinsicMaxTrackBreadth()` are allowed to grow beyond growth limits. This is the case for `fit-content(0)` or `auto` but not for `max-content`. That seems like a bug in Chrome to me. "For intrinsic minimums" should include `max-content` min-sizing functions too, and some of those might match the second bullet, e.g. `minmax(max-content,max-content)` should be allowed to grow beyond limits in the "For intrinsic minimums" step. Regarding the meaning of the "For this purpose, `fit-content()` tracks..." paragraph, I think the intention is that `fit-content()` counts as `max-content` in the conditions in the bullets, then while distributing space to the selected tracks we apply the clamping - if we find that a `fit-content()` track has reached its limit, then we remove it from the selected tracks and continue with the rest. However, if the set becomes empty, then the "if there are no such tracks, then all affected tracks" rule kicks in and at that point we include all the affected tracks again (also those that didn't match the bullets originally, but this time around we distribute without clamping, since now fit-content(50px) behaves as 50px which can grow beyond limits!). I think that's the intention of the spec as it's written and it makes sense to me. For example, changing your example to `grid-template-rows: max-content fit-content(50px)`, we should grow both rows equally in this step, but the second row will be clamped at 50px, then the first row will continue to grow and soak up the remaining space. However, for `grid-template-rows: fit-content(40px) fit-content(50px)`, the first grows to 40px and the second to 50px, but then, since the set of affected tracks is now empty, we start to distribute equally to both rows again, which results in the second row being 10px larger. (This makes sense to me since it behaves as `grid-template-rows: minmax(auto,40px) minmax(auto,50px)` but without the `max-content` max-sizing part. (In your example it would give the same result.)) In general, this has the effect that we'll prioritize the tracks that has an intrinsic max-sizing function (per the conditions in the bullets) but only up to their `fit-content()` limit. If all intrinsic max-sizing functions are `fit-content()`, then **non-intrinsic** max-sizing tracks also gets a chance after the `fit-content()` limits are reached. E.g. `grid-template-rows: minmax(auto, 40px) fit-content(50px)` starts to distribute beyond limits to both tracks after the second has reached 50px, but this only happens if there are no other (unlimited) intrinsic max-sizing tracks since they will always soak up all space. -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3621#issuecomment-491116863 using your GitHub account
Received on Friday, 10 May 2019 00:58:10 UTC