[css-sizing] Computing min-width/min-height: auto to zero #2230
When exactly does 'auto' compute to zero?
The wording in Flexbox https://www.w3.org/TR/css-flexbox-1/#min-size-auto isn't particularly clear.
Does it compute to zero
We should probably bias towards computing to
The text was updated successfully, but these errors were encountered:
…f on flex items always. #2230 Pending WG approval.
I get other results:
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-sizing] Computing min-width/min-height: auto to zero
<dael> github: https://github.com//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
[EDIT: the minutes & previous comment have now been clarified - thanks!]
…t}:auto" to *always* return "auto" for flex/grid items, per CSSWG resolution. r=bradwerth This change is in response to this CSSWG resolution: "RESOLVED: compute min-width/min-height: auto to auto" w3c/csswg-drafts#2230 (comment) ...which was later clarified as only being applicable to grid/flex items (in both axes). Other layout modes may get further min-width/min-height clarification, but for now we'll leave that behavior the same (returning 0 from getComputedStyle). MozReview-Commit-ID: 2wLYDAOj9I6 --HG-- extra : rebase_source : c5f384ef5ae906e20a6e10da20c39b0a5eb226eb