Re: [csswg-drafts] [css-sizing-3] Why was min-content, etc. redefined to do nothing in the block axis? (#3973)

I believe I'm to write up Chrome's behavior (before we removed it), not write a full spec. so here it is--

We treat this very similar to height: auto -- at the end of layout, we store the height that the box ended up with before clamping it according to height/min-height/max-height. There is no need (and really, no way) to calculate this in a separate pass because never need this value outside of layout.

For orthogonal flows, we basically treat this like height: auto again. In the typical case they need to be laid out to find their width; so this fits in well with that.

The only downside is that percentages do resolve to the value they have during layout. This isn't a problem in practice. (Come to think of it, maybe the spec requires us to always resolve percentages relative to height: min-content as auto... not sure). The only place that does require special handling is flex (and, I assume, grid) due to the multi-pass layout that shrink an object -- you don't want a height: 100% child prevent flex-shrinking. So for this case, when we do the initial pass to resolve flex-basis: auto and min-height: auto, we set a flag to treat percentages as auto, which will get fixed up during the flexing pass.

-- 
GitHub Notification of comment by cbiesinger
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3973#issuecomment-612721204 using your GitHub account

Received on Monday, 13 April 2020 02:30:50 UTC