You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-sizing] Percentage sizing section is kind of vague #1132
Percentages specify sizing of a box with respect to the box’s containing block.
Although this may require an additional layout pass to re-resolve percentages in some cases, the auto, min-content, max-content, and fit-content values of min-width and min-height do not prevent the resolution of percentage sizes of the box’s contents. However, in order to prevent cyclic sizing in the general case, percentages do not otherwise resolve against indefinite sizes, and instead are treated as auto.
I actually think the text is wrong, in that sizes can only be resolved against definite sizes but the text does not specify that limitation. But beyond that:
The text implies that max-height can affect percentage resolution of the height (if it is something like min-content), but does not specifically say so
It seems to imply also that min-content will never prevent percentage resolution of children, but I am not sure that my reading is correct and would appreciate clarification
It would be nice to clarify that while max-content can prevent percentage resolution of children/descendants, it never affects the value the percentage gets resolved against (that value is always the specified height). OR, if I misunderstood, it would be good to explicitly say so.
We rewrote the entire section, because even we found it pretty inscrutable! It's definitely still under review and open to edits, so please let us know what you find bad or wrong.
The text implies that max-height can affect percentage resolution of the height (if it is something like min-content), but does not specifically say so
It should now be much clearer that it does do so.
It seems to imply also that min-content will never prevent percentage resolution of children, but I am not sure that my reading is correct and would appreciate clarification
Did you mean 'min-width/height' here? If so, then yes, it never prevents resolution of child percentages, if they could resolve otherwise (ignoring the min-size property). This should also be much clearer now.
(Flexbox and Grid explicitly say that "min-*: auto" doesn't prevent percentage resolution; it doesn't seem any more difficult to apply that to all the intrinsic keywords, we think. Please let us know if we're wrong!)
It would be nice to clarify that while max-content can prevent percentage resolution of children/descendants, it never affects the value the percentage gets resolved against (that value is always the specified height). OR, if I misunderstood, it would be good to explicitly say so.
Again, assuming you mean 'max-width/height'. 'max-height' can indeed prevent percentage resolution. As currently written, 'max-width' does not, and it does affect what size the percentage resolves against. Should either of these be different?
Thanks, this is much better. It addresses my previous comments. But I think the rewrite does not address the case where the percentage in question is specified for a min- or max-size property. For example:
"When calculating the containing block’s size, the percentage behaves as auto."
auto is not valid for max and is probably not the intention for min, here.
As a sidenote:
"Similarly, percentage margins and padding behave as zero in such cyclic cases when calculating the containing block’s size"
I believe this is incompatible with Gecko's current implementation (from memory -- I did not retest)
OK, so, afaict: width/min-width/max-width values containing a percentage are treated as the property's initial value for the purpose of calculating the min/max-size contributions. Afterwards, they resolve. E.g. in width (or min/max-width): calc(300px + 40%) we ignore the 300px as well as the percentage while calculating its size contribution.
However, we still need some text to explain the behavior of padding/margin/flex-basis and other properties, right? If yes, I would be fine reusing the same logic if we have rough interop (or, like in the margin case, no interop at all anyway).
One thing that's ambiguous in the text is whether "containing a percentage" means syntactically containing a percentage or mathematically containing a percentage -- that is, whether expressions like calc(50px + 0%) contain a percentage. In Gecko I think they do, although I'm not 100% sure.
I'd also note that the proposed text doesn't match Gecko behavior for margins and padding, where we currently account for percentages in a way that's not quite correct but pretty close, and the obvious change to stop doing that would causes us to treat only the percentage component of a calc() as 0. So please do test that this matches the behavior of other implementations for margin and padding (i.e., that they don't use the non-percent components). If that's not the case, then we likely need different behavior for width/height (and min-* and max-*) versus margin/padding.
The Working Group just discussed [css-sizing] Percentage sizing section is kind of vague, and agreed to the following resolutions:
RESOLVED: Accept the edit in https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845 with a clarification and a hyperlinked term.
The full IRC log of that discussion
<dael> Topic: [css-sizing] Percentage sizing section is kind of vague
<dael> github: https://github.com//issues/1132#issuecomment-363623845
<dael> fantasai: Sizing issue was that we...we're asking for review of the comment: https://github.com//issues/1132#issuecomment-363623845
<dael> astearns: There is a test. There are proposed edits in the comment.
<dael> astearns: Basically you either want a resolution to make the edit or reasons why not or things to improve?
<dael> fantasai: Yeah. Looking for review.
<dael> fantasai: For margins and padding case I think it's asep issue that we need to discuss.
<dael> fantasai: This text is just about sizing properties. margins is not a sizing property.
<dael> fantasai: For margins and padding we could honor whatever is in the calc that's n ot the % and treat % as 0. I suspect that would not cause a problem and makes a bit of sense to do if we can.
<dael> fantasai: For sizing properties it's more complicated because you want ot be able tomeasure the content. but for margins and padding there isn't a thing to measure. So we could resolve % against 0 to calc the contining block rather then ignore the margin entirely.
<dael> franremy: This was brought up 2 weeks ago. me and dbaron reviewed and I think we were both fine with the proposal. dbaron pointed out you want to link to the sizing properties. I think this is fine. We found more htings tow ork on but it's fine to open a new issue.
<dael> dbaron: The one sentence...the one comment is I think containing a % could be two different things. It could be syntatic or mathematic.
<dael> franremy: I think there is a test that covered this. We can clarify the text, but there is a test I think.
<dael> fantasai: Yeah, we need clarification.
<dael> dbaron: I'm fine given the clarification and hyperlink.
<dael> astearns: Other comments?
<TabAtkins> tabatkins: 0% definitely should count as "containing a percentage".
<dael> astearns: Does anyone object to the change with the clarification and hyperlink?
<fantasai> Discussion of margins is kinda mixed in here : https://github.com//issues/2297
<dael> RESOLVED: Accept the edit in https://github.com//issues/1132#issuecomment-363623845 with a clarification and a hyperlinked term.
<dael> fantasai: I think margin stuff is in issue #2297
<dael> astearns: So franremy please look there and see if you can continue in that or open a sep issue
Activity
tabatkins commentedon Aug 8, 2017
We rewrote the entire section, because even we found it pretty inscrutable! It's definitely still under review and open to edits, so please let us know what you find bad or wrong.
It should now be much clearer that it does do so.
Did you mean 'min-width/height' here? If so, then yes, it never prevents resolution of child percentages, if they could resolve otherwise (ignoring the min-size property). This should also be much clearer now.
(Flexbox and Grid explicitly say that "min-*: auto" doesn't prevent percentage resolution; it doesn't seem any more difficult to apply that to all the intrinsic keywords, we think. Please let us know if we're wrong!)
Again, assuming you mean 'max-width/height'. 'max-height' can indeed prevent percentage resolution. As currently written, 'max-width' does not, and it does affect what size the percentage resolves against. Should either of these be different?
[css-sizing] Try to actually define how % and intrinic sizes work. Re…
cbiesinger commentedon Nov 5, 2017
Thanks, this is much better. It addresses my previous comments. But I think the rewrite does not address the case where the percentage in question is specified for a min- or max-size property. For example:
"When calculating the containing block’s size, the percentage behaves as auto."
auto is not valid for max and is probably not the intention for min, here.
As a sidenote:
"Similarly, percentage margins and padding behave as zero in such cyclic cases when calculating the containing block’s size"
I believe this is incompatible with Gecko's current implementation (from memory -- I did not retest)
fantasai commentedon Jan 19, 2018
OK, so, afaict: width/min-width/max-width values containing a percentage are treated as the property's initial value for the purpose of calculating the min/max-size contributions. Afterwards, they resolve. E.g. in
width (or min/max-width): calc(300px + 40%)we ignore the 300px as well as the percentage while calculating its size contribution.This needs edits and testcases.
fantasai commentedon Feb 6, 2018
(Wrt sidenote, IIRC Gecko agreed to change their behavior. See #347.)
[css-sizing-3] Add tests for intrinsic size contribution (width/inlin…
14 remaining items
fantasai commentedon Mar 6, 2018
@FremyCompany Margin is not a sizing property. https://drafts.csswg.org/css-sizing-3/#sizing-property
FremyCompany commentedon Mar 6, 2018
@fantasai The text definitely looks fine then.
However, we still need some text to explain the behavior of padding/margin/flex-basis and other properties, right? If yes, I would be fine reusing the same logic if we have rough interop (or, like in the margin case, no interop at all anyway).
dbaron commentedon Mar 7, 2018
One thing that's ambiguous in the text is whether "containing a percentage" means syntactically containing a percentage or mathematically containing a percentage -- that is, whether expressions like
calc(50px + 0%)contain a percentage. In Gecko I think they do, although I'm not 100% sure.I'd also note that the proposed text doesn't match Gecko behavior for margins and padding, where we currently account for percentages in a way that's not quite correct but pretty close, and the obvious change to stop doing that would causes us to treat only the percentage component of a
calc()as0. So please do test that this matches the behavior of other implementations formarginandpadding(i.e., that they don't use the non-percent components). If that's not the case, then we likely need different behavior forwidth/height(andmin-*andmax-*) versusmargin/padding.dbaron commentedon Mar 8, 2018
OK, based on @fantasai's comments in the telecon,
sizing propertyneeds to be hyperlinked to the definition; I wasn't aware it was a term.css-meeting-bot commentedon Mar 8, 2018
The Working Group just discussed
[css-sizing] Percentage sizing section is kind of vague, and agreed to the following resolutions:RESOLVED: Accept the edit in https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845 with a clarification and a hyperlinked term.The full IRC log of that discussion
<dael> Topic: [css-sizing] Percentage sizing section is kind of vague<dael> github: https://github.com//issues/1132#issuecomment-363623845
<dael> fantasai: Sizing issue was that we...we're asking for review of the comment: https://github.com//issues/1132#issuecomment-363623845
<dael> astearns: There is a test. There are proposed edits in the comment.
<dael> astearns: Basically you either want a resolution to make the edit or reasons why not or things to improve?
<dael> fantasai: Yeah. Looking for review.
<dael> fantasai: For margins and padding case I think it's asep issue that we need to discuss.
<dael> fantasai: This text is just about sizing properties. margins is not a sizing property.
<dael> fantasai: For margins and padding we could honor whatever is in the calc that's n ot the % and treat % as 0. I suspect that would not cause a problem and makes a bit of sense to do if we can.
<dael> fantasai: For sizing properties it's more complicated because you want ot be able tomeasure the content. but for margins and padding there isn't a thing to measure. So we could resolve % against 0 to calc the contining block rather then ignore the margin entirely.
<dael> franremy: This was brought up 2 weeks ago. me and dbaron reviewed and I think we were both fine with the proposal. dbaron pointed out you want to link to the sizing properties. I think this is fine. We found more htings tow ork on but it's fine to open a new issue.
<dael> dbaron: The one sentence...the one comment is I think containing a % could be two different things. It could be syntatic or mathematic.
<dael> franremy: I think there is a test that covered this. We can clarify the text, but there is a test I think.
<dael> fantasai: Yeah, we need clarification.
<dael> dbaron: I'm fine given the clarification and hyperlink.
<dael> astearns: Other comments?
<TabAtkins> tabatkins: 0% definitely should count as "containing a percentage".
<dael> astearns: Does anyone object to the change with the clarification and hyperlink?
<fantasai> Discussion of margins is kinda mixed in here : https://github.com//issues/2297
<dael> RESOLVED: Accept the edit in https://github.com//issues/1132#issuecomment-363623845 with a clarification and a hyperlinked term.
<dael> fantasai: I think margin stuff is in issue #2297
<dael> astearns: So franremy please look there and see if you can continue in that or open a sep issue
[css-sizing-3] Add tests for intrinsic size contribution (width/inlin…
Bug 1436404 [wpt PR 9418] - [css-sizing] Intrinsic percentage non-rep…
[css-sizing] Specify that sizing properties containing %s are treated…
Bug 1436404 [wpt PR 9418] - [css-sizing] Intrinsic percentage non-rep…
Bug 1436404 [wpt PR 9418] - [css-sizing] Intrinsic percentage non-rep…
Bug 1436404 [wpt PR 9418] - [css-sizing] Intrinsic percentage non-rep…
Bug 1436404 [wpt PR 9418] - [css-sizing] Intrinsic percentage non-rep…