- From: Javier Fernandez Garcia-Boente via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 May 2018 08:58:57 +0000
- To: public-css-archive@w3.org
Ok, I think we have an agreement on the proposed changes, so that these new steps 1.5 and 2.5 will produce better results. I also agree that it shouldn't interfere with row estimation in case of orthogonal items, which will be addressed in the extra cycle, as tab mentioned. > That's basically what Gecko does too. The proposed change doesn't affect that in any way though, since distribution of space only happens when the grid container has a definite size in that axis (so it doesn't occur during intrinsic sizing). Well, I was talking about a case where an orthogonal item spans several rows in a grid with a definite height. For example: ``` <div style="display: inline-grid; grid-template-rows: 50px 50px; height: 200px; font: 20px/1 Ahem; justify-content: start; align-content: space-between;"> <div style="grid-row: span 2; background: cyan; writing-mode: vertical-lr">XXX XX X XX X XXX</div> </div> ``` While in Firefox the example above is not rendered correctly because it doesn't perform a estimation of the row size, in Chrome it renders correctly, but column tracks are not computed correctly (at least not as good as we intend with the new steps we added now). The reason is that, as you said, row estimation happens during step 1, hence, it doesn't take Content Alignment into account. Once the preferred width is set, we can't change it, even if the actual rows's size is bigger during layout. Anyway, I don't think this is a blocker to land the changes in the spec to add the new steps in the sizing algorithm. -- GitHub Notification of comment by javifernandez Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-391273759 using your GitHub account
Received on Wednesday, 23 May 2018 08:59:00 UTC