Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-sizing] Decide how to handle `min-width/min-height: auto` for non-grid/flex items #2248
What should happen for other elements? Right now the spec doesn't say (so it implies that it'd still compute to itself everywhere, which I don't think matches reality)... Previously it was defined as computing to 0 for these elements.
Suggestion: how about we say the resolved value of this
Ah, now I see that the spec does actually say that
I was misled/confused by the main definition of this property/value further up, in CSS-Sizing Section 3.1:
I'm pretty sure the "lengths made absolute" text there does not affect "auto" (because "auto" is not a
Perhaps we need some "see prose" caveat in the "Computed" line?
@dholbert was pointing out that this is much easier to implement correctly, and is simpler to specify. It also neatly solves the problem of distinguishing between
A few nits on the recent spec-tweak commit for this issue:
(2) "For backwards-compatibility, the resolved value of this keyword is zero for [...] block and inline boxes" -- this isn't strictly what you want to say, because flex items are "block boxes" (if they're
(3) Is the word "zero" OK to use here, or should we use
Suggestion: maybe you can address all three of these by replacing this with some language like:
...and then other layout modes (grid/flex) should be sure to define that the
This week I landed on 7272dc5 (a lot of commits in CSS, not randomly selected, but most other things I looked at were editorial, tested, or very new feautres)
That links here. Curiously, there isn't even a css-sizing directory in https://github.com/w3c/web-platform-tests/tree/master/css, so I'm probably missing something important about the nature of this spec. Maybe what it says can only be tested indirectly through its effect on other specs? The word "must" isn't used much, at least.
Anyway, 7272dc5 looks like something for which it would be straightforward to write a test using
@dholbert, since you filed this issue, what do you think it'd take to determine whether this has been implemented or not, somewhere down the line? If this is actually a case that doesn't make sense to write tests for that's fine, I'd like to understand when that's the case too.
Here are the key things that'd be worth asserting, which are related to this issue (and please interpret "minWidth" as "both minWidth and minHeight, independently" below):
And then here's the subtle part...
That last point is the part that is new here as of 7272dc5. Previously, the spec required the parent container's default
I suspect/expect that browsers already have the behavior that I'm proposing here, since it's strictly simpler (requiring less logic / special-casing at computation time). But I'm not sure.
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
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
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-sizing] Decide how to handle `min-width/min-height: auto` for non-grid/flex items
<dael> github: https://github.com//issues/2248
<dael> fantasai: The issue is about what do we do with computed values on non-grid and non-flex items. Behave as 0. dholbert proposed auto keyword computes to itself on all display types, but the resolved value should be 0.
<dael> fantasai: This has a couple of advantages. One is that it makes the computed value easier to compute, the keyword isn't based on display type information. Second advantage is there was some behavior we were trying to resolve for anotehr issue which required us to distinguish between auto and 0 min sizes on elemnts that are no flex and grid so being able to refer to that is good.
<dholbert> *resolved & used (i guess)
<dael> fantasai: Disadvantage if you're animating from initial value of assumed 0 on the min-height and min-width, that breaks.
<dael> fantasai: No sure how many people are animating that and, if they are, assuming initial value of 0.
<dael> fantasai: I think we should take proposal, but want to hear from group. Toward the end of the issue there's discussion about a separate item that needs to file separately.
<dael> astearns: Other opinions?
<dael> astearns: Proposal is have the computed value be auto but the used value be 0?
<dael> fantasai: Used value is 0. Resolved value would be 0. CHange...currently computed value is 0, computed value remains as the keyword auto. If you use getComputedStyle we'll return 0 for backwards compat
<dael> fantasai: Kinda like we do for width where auto computes to self but getComputedStyle returns 0
<dael> astearns: Objections to this change?
<dael> RESOLVED: Accept the change in https://github.com//issues/2248#issuecomment-362114572
It's possible that implementations already match this new spec text, actually! Here's a testcase for this behavior:
In Firefox (nightly) and latest Chrome and Edge, that gives me:
Per the previous spec text, I was expecting that the last line there would say '0px' (since computed values are what are inherited, and per previous spec text, '0px' would be the computed value of the initial 'auto' on the parent of this flex item -- and so '0px' is what would inherit to the flex item that has explicit 'min-width:inherit'). But maybe the previous spec text's expectations about this edge-case were silly enough that nobody ever implemented them. :)
Basically all the css-sizing tests are within css/CSS2.
@dholbert Replying to #2248 (comment) ...
Current prose is
Didn't add the resolved value bit into the general definition, because we do want that to remain as an exception for the CSS2.1 display types only.
referenced this issue
Mar 4, 2018
This seems fine, yeah. I see you're right about flex items not being
One minor issue that still remains, with the "block and inline boxes" special callout -- technically, the new spec text doesn't define what to do with
Those table parts aren't block boxes, nor are they inline boxes, so the css-sizing spec doesn't currently define what the default
@dholbert I think the current text in Sizing covers table parts adequately: https://drafts.csswg.org/css-sizing-3/#valdef-width-auto
There's a separate question of how tables interpret