Repository navigation
[css-sizing-3] Does indefinite min-height: N% fall back to zero or auto? #2384
Description
Activity
- changed the title
[-][css-sizing-3] Does indefinite min-width: N% fall back to zero or auto?[/-][+][css-sizing-3] Does indefinite min-height: N% fall back to zero or auto?[/+]on Mar 4, 2018 Agenda+ to figure out what people think makes the most sense: treating it as '0' or as 'auto'.
The Working Group just discussed
Does indefinite min-height: N% fall back to zero or auto?, and agreed to the following resolutions:RESOLVED: treat indefinite percentages in min-width and min-height as 0
The full IRC log of that discussion
<dael> Topic: Does indefinite min-height: N% fall back to zero or auto?
<dael> github: https://github.com//issues/2384
<dael> TabAtkins: This is for min-width and height. Do they fallback to auto or 0? General rule is we fall back to initial value. Is that 0 or auto? Initial used to be 0, changed to auto.
<dael> TabAtkins: 2.1 explicitly says they're treated as 0, but it was prob on the assumption 0 was the initial value.
<dael> TabAtkins: Only real case is you have a flex item and you can't resolve the min-height should it be auto or 0?
<dael> TabAtkins: I'm of the opinion it hsould be auto.
<dael> Rossen: Current?
<dael> TabAtkins: 0 which was previous initial value.
<dael> TabAtkins: Change to be consistent with the change to initial.
<dael> fantasai: I'm trying to wrap my head around when this would be different.
<dael> astearns: Last time we discussed 0% when we said it should be 0 it's different on width then min-width.
<dael> fantasai: auto for width isn't hte same as min-width.
<dael> astearns: We could throw out the calc on min-width if it's doesn't resolve.
<dael> TabAtkins: either the percent 0s out or we throw it out.
<dael> fantasai: Makes more sense.
<dael> tantek: Treat min-width and min-height the same as we just resolved to deal with percentages.
<dael> astearns: So it's 0 rather then auto.
<dael> TabAtkins: Still a change from current. calc is replaced with 0. Current is calc(10%+10px) = 0. Now it's =10px.
<dael> fantasai: This makes the most sense. Consistent with margins and padding.
<dael> fantasai: If you set min-width to a non-auto size you're not expecting it to look at content
<dael> astearns: Prop: treat indefinete % in min-width and min-height as 0
<dael> RESOLVED: treat indefinite percentages in min-width and min-height as 0
<dael> Rossen: This is web compat?
<dael> TabAtkins: If you have a complex calc it's a change. percent only is the same.
Resolved: Zero out the percentage, as we do for margins/padding
- added a commit that references this issue
on Apr 21, 2018 - added a commit that references this issue
on May 7, 2018
In #2248 (comment) @MatsPalmgren wrote:
I was just updating some code dealing with min-width:auto and I'm wondering if min-width:N%with an indefinite percentage basis counts as auto in this context? In particular, does Automatic Minimum Size apply? https://drafts.csswg.org/css-grid/#min-size-auto
In #2248 (comment) @dholbert wrote:
I tend to think that it should apply, though I don't think any spec text says that it would. And really, CSS2 has text saying that for
min-height(which in CSS2 was the only one of themin-{size}properties that could have an indefinite basis), it falls back to '0':https://www.w3.org/TR/CSS22/visudet.html#propdef-min-height
I suspect "treated as '0'" there was really meant to signify "treated as the initial value". And so now, under that interpretation, this scenario should now fall back to
auto-which-then-usually-gets-treated-as-0... This might want its own spec issue, though.Thus, its own spec issue.