Csswg-drafts: [css-sizing] Computing min-width/min-height: auto to zero

[fantasai]

When exactly does 'auto' compute to zero?

http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20html%20%7B%20display%3A%20flex%3B%20%7D%0A%3C%2Fstyle%3E%0ATest%0A%3Cscript%3E%0A%20%20w(window.getComputedStyle(document.body%2C%20null).getPropertyValue(%27min-height%27))%3B%0A%3C%2Fscript%3E

The wording in Flexbox https://www.w3.org/TR/css-flexbox-1/#min-size-auto isn't particularly clear.

On a flex item whose overflow is visible in the main axis, when specified on the flex item’s main-axis min-size property, specifies an automatic minimum size. It otherwise computes to 0 (unless otherwise defined by a future specification).

Does it compute to zero

• on flex items, in the main axis, when 'overflow' is visible?
• on flex items, in the main axis, always? (Firefox does this)
• on flex items, in both axes? (Chrome does this)

We should probably bias towards computing to auto in as many cases as is Web-compatible, but we should also fix the spec to say exactly what happens.

[Loirooriol]

I get other results:

• On Chrome and Edge, on flex items, auto always computes to itself in both axes, even if overflow is not visible.
• On Firefox, on flex items, auto computes to itself in the main axis when overflow is visible. Otherwise it computes to 0.

[css-meeting-bot]

The Working Group just discussed [css-sizing] Computing min-width/min-height: auto to zero, and agreed to the following resolutions:

• RESOLVED: compute min-width/min-height: auto to auto

The full IRC log of that discussion

<dael> Topic: [css-sizing] Computing min-width/min-height: auto to zero

<dael> github: https://github.com/w3c/csswg-drafts/issues/2230

<dael> fantasai: I noticed we don't have consistancy on if the min height or min width go to auto or 0 on flex items. Spec isn't clear. WE should do something to make spec clear.

<dael> fantasai: I think it's in our best interest to compute to auto as many places as possible. Given blink is always auto we should go ahead and do that.

<dael> fantasai: This would change flexbox and grid spec to clarify that. min-width and min-height computes to auto

<dael> Rossen_: I thought we had a resolution. I believe in edge we're always doing auto so you can round to computed value and be able to round trip.

<dael> fantasai: The cases where it goes to 0 it would round trip. Flex items the only dimension were auto isn't 0 is the main axis. IN the cross axis it doesn't have any effect. It's effectively 0 not computed to 0.

<dael> Rossen_: In other cases you'll have wrong behavior if you round trip to 0.

<dael> fantasai: Those cases are already auto.

<dael> Rossen_: Okay.

<dael> Rossen_: Anyone from FF that wants to chime in? Seems Gecko is the only one that may need to do work.

<dael> Rossen_: Objections?

<dael> Rossen_: I don't hear obj, but there isn't large representation from Gecko. If they have additional comments the issue is there.

<dael> tantek: Is the main argument round tripping?

<dael> fantasai: Main argument is to have a simplier rule for auto. If we were going back in time we'd have auto always go to auto and never 0 so in layout modes with another meaning it's consistant. For flex there's a complex set of conditions for when auto behaves as 0. only with overflow visible and main axis. Seems simplier to compute to auto.

<dael> Rossen_: We've added a whole bunch of magic into auto for flex. We don't want to expose parts of the magic sometimes. We just want it to be always auto.

<fantasai> dholbert: yeah

<dholbert> fantasai: OK, I don't have strong opinions then

<dael> Rossen_: tantek Anything else you want?

<dael> tantek: I'm trying to understand, but no reason to object. I see dholbert is checking.

<rego> dholbert, yep only about getComputedStyle()

<dholbert> fantasai: ...except I'd prefer to avoid introducing "this property's computation [as visible through inheritance etc] depends on that property's computed value on the same element" special cases

<dael> fantasai: Argument to compute to 0 is the author gets that result immediately when we can reliably get 0. Case to compute to auto is we can make it a simple rule. You could prob. argue in either direction.

<dael> Rossen_: I'm not hearing pushback.

<dael> Rossen_: Sounds like we have 3 impl shipping the proposed behavior.

<dael> Rossen_: I'm going to call for objections. Any objections?

<dael> RESOLVED: compute min-width/min-height: auto to auto

[dholbert]

[EDIT: the minutes & previous comment have now been clarified - thanks!]

I'm confused about the resolution here. The end of the minutes had this:

Rossen_: Sounds like we have 3 impl shipping the proposed behavior.
12:32 PM Rossen_: I'm going to call for objections. Any objections?
12:32 PM RESOLVED: compute min-width/min-height: auto to zero

I assume the 3 impl are Webkit/Blink/Edge, but according to https://github.com/w3c/csswg-drafts/issues/2230#issuecomment-361013696 , those 3 impls all compute min-width/min-height:auto to itself in both axes, which is not what the resolution said to do. Can someone clarify what the resolution was?

[tantek]

Also please clarify whether this resolution is ONLY for grid and flex items, or has broader scope.

[fantasai]

Fixed the minutes, clearly they were wrong. Grid and flex items only; other things can be considered as separate issues on a case by case basis.

[tantek]

From IRC:

Rossen_: RESOLVED: computed value of min width and min height is auto even if it's internally resolved to 0 for layout purposes

and yes for grid & flex items only, anything else file that separate

[fantasai]

I believe this is fixed in the specs; please re-open if there is anything unclear about it in css-grid/css-flexbox/css-sizing!