[css-sizing] Percentage margins and intrinsic sizes

[fantasai]

Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4345

Gecko renders as an author would expect: float is shrink-wrapped around its content with no overflow, and margins are 25% of their containing block. Blink and Edge overflow.

According to author > implementer > spec, we should all follow Gecko's lead here, but that requires buy-in from everyone else. :)

[MatsPalmgren]

Here's a testcase with some examples - the box at the top is a flexbox and the second is a block, both with percentage padding, and the two boxes at the end are grids with percentage padding/margin and percentage grid-gap and grid-item percentage padding:
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.html
and here's how it renders in Firefox Nightly and Chrome Canary respectively:
https://people-mozilla.org/~mpalmgren/tests/grid/percent-intrinsic-sizing.png

[css-meeting-bot]

The CSS Working Group just discussed %s in intrinsic sizing, and agreed to the following resolutions:

• RESOLVED: percentage margins & paddings compute to 0 in intrinsic sizing and then resolve during layout

The full IRC log of that discussion

<gregwhitworth> Topic: %s in intrinsic sizing
<astearns> github: https://github.com//issues/347
<dbaron> github: https://github.com//issues/347
<gregwhitworth> TabAtkins: we normally set % margins to 0
<gregwhitworth> TabAtkins: Edge/Chrome does this when flex asks for intrinsic sizing
<gregwhitworth> TabAtkins: Firefox backcomputes this information to resolve the %
<gregwhitworth> TabAtkins: that implementation in general is scary and weird, I'd prefer to avoid it
<gregwhitworth> TabAtkins: If FF plans to keep this would they please spec it, or discuss what to do
<gregwhitworth> Rossen: didn't we discuss this in seattle
<gregwhitworth> fantasai: that was about width
<gregwhitworth> dbaron: we're trying to figure out the contribution of the intrinsic of it's parent
<gregwhitworth> dbaron: we consider it's intrinsic size and it's margin, border, padding
<gregwhitworth> dbaron: your source of width, might be the width property, *explains the rest of the math*
<TabAtkins> (sum of lengths)/(1 - sum of %s) = container width
<Rossen> gsnedders, yes, the test passes
<TabAtkins> Rather, = width you resolve %s against on that element
<dbaron> https://dbaron.org/css/intrinsic/#outer-intrinsic
<gregwhitworth> iank_: in your intrinsic sizes, it computes its content size
<gregwhitworth> iank_: ignoring padding, margin, border
<gregwhitworth> iank_: then the parent takes the content size and looks at the border, margin, padding and looks at the % as well and takes into account all %s of its children
<gregwhitworth> dbaron: no, it only takes one at a time
<gregwhitworth> Rossen: which is where it falls apart
<gregwhitworth> TabAtkins: tables don't have to worry about lines, that's why they can do them
<gregwhitworth> dbaron: what did we resolve in Seattle
<gregwhitworth> dbaron: I thought we resolved to not do it since it doesn't take siblings into account for intrinsic sizing
<gregwhitworth> Rossen: that's what I recall, I'm reviewing the minutes now
<gregwhitworth> astearns: does that resolution go against what gecko currently does
<gregwhitworth> dbaron: that means some things may not fit, but we're not perfect so... meh
<gregwhitworth> astearns: does anyone have any other issue
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0088.html
<astearns> other issue was https://github.com//issues/1051 ?
<gregwhitworth> Rossen: we resolved that %s will behave as auto
<fremy> https://github.com//issues/509 is still open
<fremy> "Percentage resolution for margins"
<fremy> https://github.com//issues/509#issuecomment-277119468
<fremy> "myles RESOLVED: "Percentages contribute intrinsic size and they resolve after layout""
<gregwhitworth> astearns: sounds like some additional archiving needs to happen?
<gregwhitworth> Rossen: oh hold on
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0061.html
<gregwhitworth> Rossen: this was the related discussion about grid & %s
<gregwhitworth> TabAtkins: what happens if the %s go higher than 100%
<gregwhitworth> dbaron: we cap it
<gregwhitworth> TabAtkins: there's a bit of a discontinuity there
<gregwhitworth> dbaron: right
<gregwhitworth> dbaron: we cap at 100% so that we don't go to infinity
<gregwhitworth> Rossen: after we did all of the issues in Seattle we had consensus to go with that go to 0 but they still resolve
<Rossen> https://lists.w3.org/Archives/Public/www-style/2017Feb/0061.html
<dbaron> TabAtkins, https://searchfox.org/mozilla-central/rev/bbc1c59e460a27b20929b56489e2e55438de81fa/layout/base/nsLayoutUtils.h#1455-1470
<gregwhitworth> Rossen: the resolution doesn't make much sense, but if you follow the discussion, there is a 0 intrinsic size
<gregwhitworth> Rossen: after the straw poll that's what we resolved for
<gregwhitworth> TabAtkins: yeah this was for widths
<gregwhitworth> Proposed resolution: percentage margins compute to 0 in intrinsic sizing and then resolve during layout
<gregwhitworth> RESOLVED: percentage margins & paddings compute to 0 in intrinsic sizing and then resolve during layout