I would recommend filing a github issue for the css-sizing spec about this.

+fantasai fyi

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30eb4e109b74ecc63685a063ce18d1604c1da35e

commit 30eb4e109b74ecc63685a063ce18d1604c1da35e
Author: Morten Stenshorne <mstensho@chromium.org>
Date: Sat Feb 03 03:49:33 2018

[LayoutNG] Simplify and correct LayoutNewFormattingContext().

Let the layout algorithm for a child figure out the size of the child,
instead of estimating it in LayoutNewFormattingContext(). Gets rid of
the "fixed inline size" case. This also means that we're trusting
legacy layout more than before to correctly size legacy objects (such
as tables, flexbox and replaced content), so we need to be more
careful to provide legacy layout with the correct input data, i.e.
the containing block size override. In particular, we cannot always
use the percentage resolution size from the constraint space to
resolve widths and heights on the child (only do that if the specified
size is indeed a percentage; otherwise use available size, which has
been adjusted for adjacent floats). Some work was also needed to make
sure that legacy layout also respects this override to a greater
extent than before.

Absolutely positioned objects are still not allowed to size themselves
(legacy or not). Not sure if that's good in the long run (then again,
sizing of absolutely positioned objects is rather special). There was
one missing check for content logical height override for abspos
objects, which suddenly became an issue, and had to be fixed.

Remove margin hacks for LayoutTable. Similar hacks would have been
needed for flexbox, grid, etc. anyway. Instead, have
LayoutNewFormattingContext() add the child's inline margins to the
layout opportunity, so that all algorithms resolve auto inline sizes
correctly (typically by subtracting margins from available
space). Even pure NG layout algorithms need this.

If it turns out (after layout) that the child won't fit within the
layout opportunity found, find a new opportunity and lay out
again. Repeat this step until we find something that fits. This
potentially results in more layout passes than before, but we're going
to have to do this for block fragmentation anyway, so better be
consistent about it.

Quite a few tests started to pass. Then, also, two tests regressed,
both pertaining to the non-standard width:-webkit-fill-available declaration.
One of the changes almost looks like an improvement, but it's not compatible
with other engines. The spec is unclear.

Bug: 807708, 807830

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Idf9f20c89640ea1c8d7659865a265e889c8211fd
Reviewed-on: https://chromium-review.googlesource.com/888059
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Emil A Eklund <eae@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534254}
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/LayoutTests/FlagExpectations/enable-blink-features=LayoutNG
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/LayoutBox.cpp
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/LayoutTable.cpp
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/ng/geometry/ng_bfc_rect.h
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.h
[modify] https://crrev.com/30eb4e109b74ecc63685a063ce18d1604c1da35e/third_party/WebKit/Source/core/layout/ng/ng_block_node.cc