Re: [csswg-drafts] [css-align][css-sizing] Indefinite percentages in calc() are underspecified

>From the author's side, I would definitely expect `calc(10px + 20%)` to always equal _at least_ 10px, for margin or padding or anything else.

I also would very much prefer that contents inside a shrink-to-fit container don't end up adding extra spacing after the container has been fit, unless the percentages sum up to greater than 100%.

Based on those objectives, I see two acceptable approaches. Either:

* calculate the container width using an algebra equation:

  - 100%*width = ∑(fixed widths) + ∑(percentage widths)*width
  - (100% - ∑(percentage widths) ) * width = ∑(fixed widths)
  - width = ∑(fixed widths) / (100% - ∑(percentage widths) ) 
  - AKA, for Mat's example, the width would be 110px/80% = 137.5px

* *Or,* treat the reference for percentage widths as 0, calculate out the rest of the expression, and stick with it even after the container width is resolved. Less ideal, but simpler.

***That said***, the consistent behavior for all browsers I've tested for

-  [`width` defined as a percentage + absolute length](https://codepen.io/AmeliaBR/collab/ba68490f0470fcf5917a8a4eb440c924/) in shrink-to-fit containers is to treat the entire `calc` expression as zero when determining the parent container's width, but then evaluate the `calc` for the children normally after the parent width is set (so the child elements now overflow the too-small parent).

-  [`height` defined as a percentage + absolute length](https://codepen.io/AmeliaBR/pen/c1a8fb61843e50986f0b0e1b49c2e4ec/) in contexts where percentage height isn't defined (because of a fit-to-contents auto-height parent container) is to treat the entire `calc` expression as unresolvable, setting the height to `auto`.

I'm not sure where/if either of those behaviors are defined ([CSS sizing says to refer to the individual layout modules](https://drafts.csswg.org/css-sizing-3/#sizing-values) for how to resolve percentages, and doesn't mention `calc`).

If height and width were consistent with each other, I'd argue that padding & margin should match the same behavior, too. But they aren't. They're a mess. So I refer again to my suggested solutions above, and wonder if there would be any compat issue with making `width` in a shrink-to-fit container behave similarly. *(The algebra isn't that complicated, really…)*


-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2297#issuecomment-370243991 using your GitHub account

Received on Sunday, 4 March 2018 16:50:04 UTC