RE: [css-grid] Should we re-run the sizing algo on max-content size changes, too?

On 04/11/2016 04:11 PM, Tab Atkins Jr. wrote:> 
> This is about Grid DoC Issue 20
> <https://drafts.csswg.org/css-grid/issues-wd-20150917#issue-20>.
> 
> Currently, step 3 of the Grid Sizing Overview <https://drafts.csswg.org/css-

> grid/#algo-overview> requires that you rerun the sizing algorithm once if any
> of the grid items had their min-content contribution changed due to Step 2.
> This catches things where their inline size depends on the available space in
> the block dimensions, such as column-wrap flexboxes, or orthogonal flows,
> and gives them a chance to stabilize to a "correct" size.  (Theoretically this is
> iterate-until-stable layout, but apparently it's good enough to just do it twice,
> at least according to MS's initial
> implementation.)
> 
> This step has been present since the original Microsoft algorithm
> <https://www.w3.org/TR/2013/WD-css3-grid-layout-20130402/#layout-

> algorithm>,
> and it's always been solely about changing min-content contributions.
> But what about max-content contributions?  Some parts of the algo do care
> about max-content, and it seems like that would have a similar set of
> problems if we didn't adjust for it.
> 
> Can anyone think of a good reason why that step only fires on min-content
> contribution changes, and not max-content?  If not, does anyone object to
> us making it fire on max-content contribution changes as well?

Our concern that led to this step was overflow.  We were trying to avoid scenarios where the final row height caused an item's children to overflow the column, and interpreting 'min-content' as 'minimum width that avoids overflow' led to this approach.

This isn't a particularly rigorous solution (as you pointed out earlier) so we constrained it solely to avoid overflow.

I don't have a strong opinion on whether this step should be expanded to include max-content, but I'd be curious to see examples of layouts where it would make a difference.

Thanks,
Peter

Received on Monday, 11 April 2016 22:52:00 UTC