[css-grid] Do all percentages behave as auto when computing minimum contribution?

[Loirooriol]

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.

[Loirooriol]

In https://crbug.com/931474 I have fixed Blink to behave like Firefox.

[fantasai]

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]

@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

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.

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 with min-width:0 we thus have width:0 so the item's minimum contribution is zero resulting in a zero column size. When calculating the item's used value for width during layout the column size is definite so we resolve 100% of 0 making the item have zero width.

[Loirooriol]

@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]

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.

Exactly. This is what I said.

So we decided for "depends on the size of its containing block".

Are you saying that you don't want to resolve 100% against the grid area's size after that size is known?!?

[Loirooriol]

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]

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:

  <p style="width: 100px">
    <div style="width: 100%"></div>
  </p>

then the width of the div definitely depends on the width of the p. 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]

I don't like this new incompatible definition of "behaves as auto".

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 auto at some points and different than auto at other points is a relatively new thing of grid and flex layout.

A percentage always depends on its percentage basis to be resolved.

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]

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.

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.

I had the impression that percentages being treated as auto at some points and different than auto at other points is a relatively new thing of grid and flex layout.

It's always been like that as far as I know. This isn't specific to Grid/Flex layout, a simple float will do:

<div style="float:left; border:solid">
  <div style="width:200%; background:lime">abc</div>
</div>

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 so 200% does not behave as auto there - it's simply resolved against that definite inline-size.

Can you clarify why you think this definition is incompatible?

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% of 100px)

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.

Yes, that's why we used "depends on the size of its containing block", we wanted to include percentages.

OK, but you also need to avoid including 100% of 100px there because we clearly don't want to treat that as auto.

Just checking "behaves as auto" wasn't including percentages.

Right, the new definition of "behaves as auto" never includes percentages AFAICT.

[Loirooriol]

This isn't specific to Grid/Flex layout, a simple float will do

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?

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

For example, block-size: 200% in block layout, when the container has an auto size. It behaves exactly as block-size: auto. The percentage is not resolved once we know the size of the containing block.

that term captures too much since all percentages depend on their percentage basis

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% of 100px because we don't know the size of the grid area, so it will be 100% 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]

note it was undefined behavior in CSS2

But the behave as auto is in css-sizing, not CSS2. I always understood css-sizing as applying to all of CSS.

I think in CSS2 there was no case in which a percentage behaved as auto at some points and not at others?

Well, floats are in CSS2, so the float example I gave demonstrates there is, right?

For example, block-size: 200% in block layout, when the container has an auto size.

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 that block-size: 200% does not behave as auto in block layout in quirks mode.)

We can't have 100% of 100px because we don't know the size of the grid area, so it will be 100% of undefined.

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.

Anyways, for discussing the exact definition of "to behave as auto" it may be better to file a new issue against css-sizing.

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]

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]

Spec fix: bf1450a
Firefox fix: https://bugzil.la/1462854
Chromium fix: https://crbug.com/931474
WebKit fix: https://webkit.org/b/195967
WPT:

• css/css-grid/grid-definition/grid-minimum-contribution-with-percentages.html
• css/css-grid/grid-items/grid-item-percentage-sizes-001.html
• css/css-grid/grid-items/grid-item-percentage-sizes-002.html
• css/css-grid/grid-items/grid-item-percentage-sizes-003.html