Repository navigation
[css-sizing-3] Does indefinite min-height: N% fall back to zero or auto? #2384
Description
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 the min-{size} properties that could have an indefinite basis), it falls back to '0':
The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the percentage value is treated as '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.
Activity
[-][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?[/+]tabatkins commentedon Mar 26, 2018
Agenda+ to figure out what people think makes the most sense: treating it as '0' or as 'auto'.
css-meeting-bot commentedon Apr 10, 2018
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 0The 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.
fantasai commentedon Apr 10, 2018
Resolved: Zero out the percentage, as we do for margins/padding
[css-sizing-3] Fix up percentage sizing per WG resolution--zero out m…
[css-sizing-3] Fix up percentage sizing per WG resolution--zero out m…