Repository navigation
[css-grid] Do all percentages behave as auto when computing minimum contribution? #3612
Description
From https://drafts.csswg.org/css-grid/#algo-single-span-items,
The minimum contribution of an item is the outer size that would result from assuming the item’s used minimum size (min-width or min-height, whichever matches the relevant axis) as its preferred size (width or height, whichever matches the relevant axis) if its computed preferred size behaves as auto, or else the item’s min-content contribution otherwise.
Percentages in preferred size are resolved with respect of the grid area. The grid area is being calculated, so I guess all percentages should be considered to behave as auto?
The change was done in #2367 as an Obvious Bugfix. Well, it doesn't seem that obvious to me, because the change was against the behavior of all Blink, Firefox and Edge at that time (Firefox later adapted to the spec in https://bugzil.la/1462854). In this example, there is no longer a green background in Firefox, but there is in Blink and Edge:
<div style="width: 0px">
<div style="display: grid; float: left; background: lime">
<div style="min-width: 0px; width: 100%">content</div>
</div>
</div>I just want to confirm whether my understanding of the spec is correct and whether this implication was intentional. In #2367 @MatsPalmgren said "percentages should behave as auto when the percentage basis is indefinite" like implying only some percentages were affected, but it seems to me that all of them are affected.
Activity
Loirooriol commentedon Mar 18, 2019
In https://crbug.com/931474 I have fixed Blink to behave like Firefox.
[css-grid-1] Clarify cases where the minimum contribution derives fro…
fantasai commentedon Jun 7, 2019
OK, clarified the spec by saying "behaves as auto or depends on the size of its containing block in the relevant axis". (Also did some editorial restructuring to make it easier to read.) See https://drafts.csswg.org/css-grid-1/#min-size-contribution
@MatsPalmgren I'd appreciate your review!
MatsPalmgren commentedon Nov 2, 2019
@fantasai I don't understand why this change was necessary. What does "or depends on the size of its containing block in the relevant axis" cover that isn't already covered by removing that bit?
In particular, the provided testcase isn't affected by that addition as far as I can tell.
@Loirooriol
All of them are affected while resolving the intrinsic track sizes because the percentage basis for a grid item is the size of its grid area which isn't known at that point (so it's indefinite). The part of the spec that is relevant for this particular testcase is the "preferred size behaves as auto" (
width:100%of an indefinite percentage basis) which leads to "its minimum contribution is the outer size that would result from assuming the item’s used minimum size as its preferred size" and withmin-width:0we thus havewidth:0so the item's minimum contribution is zero resulting in a zero column size. When calculating the item's used value forwidthduring layout the column size is definite so we resolve100%of0making the item have zero width.Loirooriol commentedon Nov 2, 2019
@MatsPalmgren I discussed this with @fantasai and @FremyCompany, and seemingly it can only be said that a value behaves as auto when specifying auto instead of that value would have no effect. In this case, a percentage is equivalent to auto while resolving the intrinsic track sizes, but once we know the size of the grid area, the percentage is no longer treated as auto. So the percentage doesn't behave as auto.
Therefore, we considered saying "contains a percentage", but this wouldn't cover things like a future
stretch. So we decided for "depends on the size of its containing block".MatsPalmgren commentedon Nov 2, 2019
Exactly. This is what I said.
Are you saying that you don't want to resolve
100%against the grid area's size after that size is known?!?Loirooriol commentedon Nov 3, 2019
It seems I didn't explain well. You said that you don't understand why this change was necessary. It was necessary because here percentages don't behave as auto, so a percentage would fall in the "else" part of the conditional. By adding "or depends on the size of the container" we made the condition hold for percentages.
I was just trying to explain why percentages are not considered to behave as auto despite not knowing the grid area yet. The reason is that, once we know the grid area, percentages will behave different than auto. So we can't consider percentages to behave as auto, since it's just a temporary thing.
MatsPalmgren commentedon Nov 4, 2019
I don't like this new incompatible definition of "behaves as auto". The old definition was contextual, meaning that a percentage behaves as auto when its percentage basis is indefinite, otherwise it's simply resolved to a definite length. This is much easier to understand and handle since a percentage is resolved in different situations: for intrinsic sizing purposes, for track sizing contributions, and eventually in layout and you'd use the percentage basis in the local context to determine if it "behaves as auto" or not.
It's also very bad to take a well-known and widely used term like this and redefine it with an incompatible meaning. We have code comments, discussions in Bugzilla, dev forums, review comments, CSSWG github issues etc etc where the term "behaves as auto" is used (with the old meaning). Those comments are now wrong and misleading due to this change.
The new term "depends on the size of its containing block" is also bad. If we have say:
then the
widthof thedivdefinitely depends on the width of thep. A percentage always depends on its percentage basis to be resolved. If that's not what you intended then it seems you're using "depends on" with a different meaning than it has in the English language.I think the old definition of "behaves as auto" worked just fine.
CC @dholbert
Loirooriol commentedon Nov 4, 2019
I also had the impression that "behaves as auto" was contextual, but I was told that the definition of "behaves as auto" is that the behavior of the value is completely indistinguishable from
auto, and for grid items percentages are only treated like auto at some points, so they don't behave as auto. IIRC, @FremyCompany was strongly convinced about this, and @fantasai agreed.Can you clarify why you think this definition is incompatible? I had the impression that percentages being treated as
autoat some points and different thanautoat other points is a relatively new thing of grid and flex layout.Yes, that's why we used "depends on the size of its containing block", we wanted to include percentages. Just checking "behaves as auto" wasn't including percentages.
MatsPalmgren commentedon Nov 4, 2019
No, no, no, that has never been the definition of the term "behaves as auto". It was always contextual, i.e. if the percentage basis was indefinite in the particular place you resolve it.
It's always been like that as far as I know. This isn't specific to Grid/Flex layout, a simple float will do:
Here,
200%behaves as auto (using the old definition) when computing the float's intrinsic inline-size, resulting in the float getting the size of "abc". When you flow the child though, the container's inline-size is now known so200%does not behave as auto there - it's simply resolved against that definite inline-size.To be clear, I said that the new definition of "behaves as auto" is incompatible with the old definition of "behaves as auto" (not that the whole new term is necessarily incompatible, although that's also true). The old definition of "behaves as auto" includes percentages resolved against an indefinite percentage basis whereas the new definition of "behaves as auto" does not. From the top of my head, I can't think of a single case where a percentage size does not have a definite percentage basis at least at some point, so percentages never "behaves as auto" with the new definition AFAICT. Thus these two definitions of "behaves as auto" are clearly incompatible.
I assume this is why "or depends on the size of its containing block in the relevant axis" was added - to capture percentages. However, that term captures too much since all percentages depend on their percentage basis (i.e. "size of its containing block"). (also
100%of100px)If you change the new term to "the size behaves as auto or is a percentage with an indefinite percentage basis" then that would be compatible with the old definition of "behaves as auto".
This new definition is more cognitively complex though, because now you have one part that is non-contextual ("behaves as auto") and one part that is contextual ("percentage with an indefinite percentage basis"). It's simpler to say that "a percentage with an indefinite percentage basis" behaves as auto.
OK, but you also need to avoid including
100%of100pxthere because we clearly don't want to treat that asauto.Right, the new definition of "behaves as auto" never includes percentages AFAICT.
Loirooriol commentedon Nov 4, 2019
OK, not restricted to Grid/Flex. I guess your example with
width: 200%doesn't behave as auto either according to the "new definition", but note it was undefined behavior in CSS2. I think in CSS2 there was no case in which a percentage behaved as auto at some points and not at others?For example,
block-size: 200%in block layout, when the container has an auto size. It behaves exactly asblock-size: auto. The percentage is not resolved once we know the size of the containing block.This is true in general, but at this step of css-grid the percentage basis is never known, so capturing all percentages seems fine. We can't have
100%of100pxbecause we don't know the size of the grid area, so it will be100%of undefined.Anyways, for discussing the exact definition of "to behave as auto" it may be better to file a new issue against css-sizing.
MatsPalmgren commentedon Nov 4, 2019
But the behave as auto is in css-sizing, not CSS2. I always understood css-sizing as applying to all of CSS.
Well, floats are in CSS2, so the float example I gave demonstrates there is, right?
True, but note that an auto-sized block's block-size is still indefinite when resolving the child's used value of
block-size, so the old definition works there too. (Also worth mentioning perhaps is thatblock-size: 200%does not behave as auto in block layout in quirks mode.)What about the block layout example I gave above? We need a general definition that works for that case too.
It's also worth noting that in resolving intrinsic row sizes, the grid area sizes are definite in the column axis so some transferred sizes (e.g. images with a ratio) involving percentages are resolved.
Fair enough, I just don't see a reason to change what is already a working definition. Especially since it's a long-standing and widely used term and thus changing it invalidates all prior discussion and comments involving this term (as I described above).
fantasai commentedon Nov 5, 2019
The definition of “behave as auto” was added in #1051 and it is very explicitly linked to the behavior in CSS2.1 where a percentage behaves as auto exactly as if its computed value were auto throughout all phases of layout. (This is the only example that is called out in the definition.)
Now, if this terminology is confusing (I'm personally not a fan) and we want to use some other terms for this behavior, that's fine. We can change it. But I don't think it's factually correct to say that it was always defined contextually, as you are asserting, @MatsPalmgren.
Loirooriol commentedon Jul 22, 2020
Spec fix: bf1450a
Firefox fix: https://bugzil.la/1462854
Chromium fix: https://crbug.com/931474
WebKit fix: https://webkit.org/b/195967
WPT: