W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

Re: [csswg-drafts] [css-grid] Stretching tracks fails to feed back into sizing algorithm

From: Manuel Rego Casasnovas via GitHub <sysbot+gh@w3.org>
Date: Mon, 03 Apr 2017 09:45:57 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-291096631-1491212756-sysbot+gh@w3.org>
I'm not sure if this will be possible without introducing other issues. For example in the case of orthogonal flows.

Let's try to illustrate that with the following example:
  <div style="display: grid; with: 500px; grid: 250px / auto auto; border: magenta solid thick; font: 100px/1 Ahem;">
    <div style="background: cyan; writing-mode: vertical-lr;">XX X X</div>
    <div style="background: yellow; writing-mode: vertical-lr;">X</div>

With the current spec `stretch` is done at the end of the grid track sizing algorithm. So this case works like:

1. On the 1st pass for the columns, the width is calculated as 100px for both columns (the items are vertical).
2. The pass for rows it's straight forward, as the row has a fixed size of 250px.
3. Then the `min-content` contribution of the 1st item has changed due to the row size, so we need to do a 2nd pass. On the 2nd pass for the columns, the width is calculated as 300px for the 1st column and 100px for the 2nd one.
4. Again the rows pass is simple as it's a fixed size.
5. Then we do `stretch` so the 1st column becomes 350px and the 2nd column 150px.

![Current behavior with stretch after tracks sizing](https://cloud.githubusercontent.com/assets/11602/24602373/ceed5680-185c-11e7-966a-93489266f332.png)

However, with the new proposal I believe this will end up in a worse result:

1. The 1st pass for columns is the same. 100px width for both.
2. But then we do `stretch`, so each column becomes 250px.
3. Then the pass for rows is again simple as it has a fixed size of 250px.
4. As the `min-content` contribution of the first item has changed again we need a new pass. On the 2nd pass for columns the 1st column has a width of 300px, and the 2nd one keeps its 250px width (the item was already sized  using the 250px of that column after the `stretch`. And here's the problem we'll have overflow on the grid container, because of the `stretch` done in step 2.

![New behavior with stretch inside track sizing](https://cloud.githubusercontent.com/assets/11602/24602620/e16451b4-185d-11e7-9e5d-10db7124d7b2.png)

As you can see in the picture, in the last case we'll be overflowing the grid container because of `stretch`, which feels really wrong as `stretch` should use the available space not more.

Last, I'm not sure if the use case is important enough to introduce changes on the track sizing algorithm at this stage. If you're using percentages on items against indefinite track sizes, I guess that having weird results in some cases can be somehow expected.

GitHub Notification of comment by mrego
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1150#issuecomment-291096631 using your GitHub account
Received on Monday, 3 April 2017 09:46:03 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:10 UTC