Skip to content

[css-sizing] Percentage sizing section is kind of vague #1132

Closed

Description

@cbiesinger

https://drafts.csswg.org/css-sizing-3/#percentage-sizing

That section is a bit vague. It currently says:

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.

Activity

  1. tabatkins commented on Aug 8, 2017

    @tabatkins
    Member

    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?

  2. cbiesinger commented on Nov 5, 2017

    @cbiesinger
    Author

    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)

  3. fantasai commented on Jan 19, 2018

    @fantasai
    Collaborator

    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.

  4. fantasai commented on Feb 6, 2018

    @fantasai
    Collaborator

    (Wrt sidenote, IIRC Gecko agreed to change their behavior. See #347.)

  5. 14 remaining items

  6. fantasai commented on Mar 6, 2018

    @fantasai
    Collaborator
  7. FremyCompany commented on Mar 6, 2018

    @FremyCompany
    Contributor

    @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).

  8. dbaron commented on Mar 7, 2018

    @dbaron
    Member

    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.

  9. dbaron commented on Mar 8, 2018

    @dbaron
    Member

    OK, based on @fantasai's comments in the telecon, sizing property needs to be hyperlinked to the definition; I wasn't aware it was a term.

  10. css-meeting-bot commented on Mar 8, 2018

    @css-meeting-bot
    Member

    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
  11. added a commit that references this issue on Apr 15, 2018
  12. added a commit that references this issue on May 7, 2018
    90c77d1
  13. added a commit that references this issue on Sep 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions