[css-grid-1] Track Sizing Algorithm question

[tabatkins]

Issue copied from original email from Jason.W He (hekylinwork@gmail.com):

---

In case of following grid.

--- 65% -- | -- 35% -- |
min-content
--- 65% -- | -- 35% -- |
auto
--- 65% -- | -- 35% -- |

Two column: 65%, 35%
Two row: min-content, auto

template-areas:
"head side"
"body side"

For row #1's track size, which it use min-content to define height of that row. When calculate height, why is row #1 been calculated using items with span of 2?

From spec, it consider items with span of 1 first, then consider at span of 2 that do not span a track with a flexible sizing function. Which the second row auto get caught.

When change second row's auto to 1fr (flexible sizing function), it now has correct behaviour.

I have sample to reproduce this under
https://codepen.io/Nness/pen/MrYMzQ?editors=1100#

When increment items inside area side. The area head's height now resize according to side.

Is this logical and correct behaviour to increase size of single span item by multiple span item?

It make sense to increase total size of multi-span grid track by item span across multiple track. How is that logical to change size of single-span grid track by item span across multiple track?

All the browser I have tested have exactly same result, does that means they all according to spec and have correct behaviour?

If use flexible sizing function is the only way to get this working and it is according to spec, then in which situation we want to use auto to have multiple span item change single span track's height behaviour?

[svillar]

From spec, it consider items with span of 1 first, then consider at span of 2 that do not span a track with a flexible sizing function. Which the second row auto get caught.

This is not correct. The second row is auto sized. Flexible sized tracks are those using fr. See https://www.w3.org/TR/css-grid-1/#layout-algorithm

When change second row's auto to 1fr (flexible sizing function), it now has correct behaviour.

Not sure what you mean with "correct" but I guess I've explained it in the previous comment.

[Nness]

This is correct behaviour. Which second row is 1fr

This is incorrect behaviour. Second row is auto

The question is, is second one acceptable result? If it is according to spec, then what kind of scenario it trying to cover? Why do we want content inside item that span multiple tracks to increase height of single track item?

This is not related to total size, I mean individual size.
You can check on sample: https://codepen.io/Nness/pen/MrYMzQ?editors=1100#

Then add more <div>push</div> into <div class="item-side">

[fantasai]

I think it makes sense to fix this--to make min-content fit tighter than auto/max-content when possible. We should draft up a change proposal for it for review... @svillar What do you think?

[tabatkins]

Flagging for f2f. We think the author expectation of this case is fairly clear and the spec would be reasonably straightforward to fix, but at this point the compat impact is very worrying and requires analysis.

[Loirooriol]

The problem seems to be in this line:

csswg-drafts/css-grid-1/Overview.bs

Line 4425 in 0dcb036

any |affected track| that happens to also have an intrinsic <a>max track sizing function</a>;

It treats all intrinsic max track sizing functions equally instead of prioritizing min-content vs auto/max-content.

[css-meeting-bot]

The CSS Working Group just discussed [css-grid-1] Track Sizing Algorithm question, and agreed to the following:

• RESOLVED: Keep working on a solution for this and take it back to the group

The full IRC log of that discussion

<fantasai> https://github.com//issues/2873#issuecomment-402552212
<emilio> fantasai: so we got an issue with a test-case with two columns, and two rows, one min-content, one auto
<emilio> ... the results that they want is the first result, which makes sense
<emilio> ... the one they get is the second
<emilio> ... the q for the working group is do we think we can fix it and do we want to?
<emilio> ... there's a compatibility concern
<emilio> q+
<emilio> fantasai: I can explain the result
<emilio> ... the first step is satisfying the minimum
<emilio> ... so min-content expands to minmax(min-content, min-content), auto expands to minmax(min-content, max-content)
<emilio> ... there's extra magic but that's roughly what happens
<emilio> ... so in the first pass we look at the items with span of 1 and the first row becomes 1 em tall, the second becomes 3em tall
<emilio> ... then we look at the spanning item
<emilio> ... and that's 10em, and since both have a min of min-content I'll distribute the extra space equally into two
<emilio> ... so the change we'd have to make is if you have two columns that are min-content but one has a max-content maximum we prefer distributing into it
<emilio> ... that's the technical direction, the question would be do we want to
<astearns> ack emilio
<TabAtkins> fantasai: Currently we grow all tracks as needed fo rmin-content sizes, then another for ....
<TabAtkins> fantasai: we'd probably put a phase between min-content and max-content
<TabAtkins> fantasai: so do we want to pursue this or does it seem unreasoanble
<emilio> dholbert: is max-content special here or would a 300px be treated similarly?
<emilio> ... same question for min-content
<florian> q+
<emilio> fantasai: when we discussed this it seemed reasonable to try to fix, author expectation seems to make more sense
<emilio> ... main q is is it web compatible
<astearns> ack florian
<emilio> florian: I think we should try, accounting with dholbert's nuanced
<emilio> ... also cross-checking with the spanning issue discussed earlier
<emilio> ... but in terms of exploring yeah
<emilio> iank_: my gut feeling is that it's hard to check whether this is web compatible, a bit of a webcompat black box
<emilio> fantasai: my guess is that authors that hit this change min-height or use fr
<emilio> iank_: yeah for this case it's clear but for other cases not so more
<emilio> astearns: iank_, are you saying this is kind of a blackbox because we don't have a solution?
<emilio> iank_: no, I just not have a good sense of how web compatible this would be
<dholbert> emilio: this seems like the sort of thing you need to try and see if it impacts the rendering/webcompat
<fantasai> emilio: and just see if you get bugs
<dholbert> emilio: I don't want to argue against it, but as dholbert noted, I'm not sure min-content / max-content are special
<dholbert> emilio: maybe we want to generically distribute space to tracks with larger maximums
<emilio> fantasai: I'm not sure doing that would be compatible, we distribute evenly in a bunch of cases
<emilio> ... min-content is special in the sense that is specifies a desire of making it as compact as possible
<emilio> dholbert: not so sure, it's more about not wanting content clipped
<emilio> astearns: there are ways to fixing things to get what you want and by not doing anything we don't risk anything
<emilio> fantasai: the workaround has some side effects that might not be totally desirable
<emilio> astearns: so... strawpoll?
<emilio> (1) do nothing, (2) try to figure out a solution for this
<florian> 2
<astearns> 2
<rachelandrew> 2
<schenney> 2
<argyle> 2
<Sammy_Gill> 2
<bramus> 2
<miriam> 2
<TabAtkins> abstain
<oriol> 2, but not sure if possible due to compat
<SebastianZ> 2
<emilio> 0
<dholbert> 2 (weak preference)
<iank_> 0
<fantasai> personal preference for 2
<stewart> 2
<emilio> RESOLVED: Keep working on a solution for this and take it back to the group
<emilio> <br>