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

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 zero`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-sizing] Computing min-width/min-height: auto to zero<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2230<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael> fantasai: This would change flexbox and grid spec to clarify that. min-width and min-height computes to auto<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael> Rossen_: In other cases you'll have wrong behavior if you round trip to 0.<br>
&lt;dael> fantasai: Those cases are already auto.<br>
&lt;dael> Rossen_: Okay.<br>
&lt;dael> Rossen_: Anyone from FF that wants to chime in? Seems Gecko is the only one that may need to do work.<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> Rossen_: I don't hear obj, but there isn't large representation from Gecko. If they have additional comments the issue is there.<br>
&lt;dael> tantek: Is the main argument round tripping?<br>
&lt;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.<br>
&lt;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.<br>
&lt;fantasai> dholbert: yeah<br>
&lt;dholbert> fantasai: OK, I don't have strong opinions then<br>
&lt;dael> Rossen_: tantek Anything else you want?<br>
&lt;dael> tantek: I'm trying to understand, but no reason to object. I see dholbert is checking.<br>
&lt;rego> dholbert, yep only about getComputedStyle()<br>
&lt;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<br>
&lt;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.<br>
&lt;dael> Rossen_: I'm not hearing pushback.<br>
&lt;dael> Rossen_: Sounds like we have 3 impl shipping the proposed behavior.<br>
&lt;dael> Rossen_: I'm going to call for objections. Any objections?<br>
&lt;dael> RESOLVED: compute min-width/min-height: auto to zero<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2230#issuecomment-362009042 using your GitHub account

Received on Wednesday, 31 January 2018 17:33:55 UTC