- From: Manuel Rego Casasnovas via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Apr 2018 10:33:02 +0000
- To: public-css-archive@w3.org
Ok, we at Igalia have been taking a look to the example. I created a reduced one, so it's easier to check the problem: http://jsbin.com/wojujiv/1/edit?html,css,output It has a grid container with 4 `auto` columns. And it has 3 images as grid items: * The first one has 300px width and spans the first 2 columns (1st and 2nd columns). * The second one has 150px width and spans the last 2 columns (3rd and 4th columns). * The third one has 250px width and spans 2nd and 3rd column. The algorithm process each of them: * For the 1st image it sets as planned increase for 1st and 2nd column 150px. * For the 2nd image it sets as planned increase for 3rd and 4th columns 75px. * For the 3rd image it sets as planned increase for 2nd and 3rd column 125px. Then it stays with the maximum for each column: * 1st column: 150px * 2nd column: 150px * 3rd column: 125px * 4th column: 75px As you see the last 2 columns measure 200px in total, when it'll be enough if they measure 150px. For example using `grid-template-columns: 150px 150px 100px 50px` would get a more packed result.  The problem is that the algorithm is trying to fulfill some preconditions. One of them is that it doesn't want the order of the items to result in different track sizes, that's why it process all the spanning items with the same span count together. It also wants to ensure that the minimum size requirements are fulfilled. And it has also the goal to have the result as compact as possible, but first he's following the previous preconditions. We're not sure if there'll be a better way to do this and if it'd have any consequences in more complex examples with different items order and so on. -- GitHub Notification of comment by mrego Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2356#issuecomment-378555399 using your GitHub account
Received on Wednesday, 4 April 2018 10:33:06 UTC