1. Propagate calc() values from StyleProperties to ComputedValues.
2. Actually resolve calc() values when determining the used flex basis.
This makes the "support" section on https://shopify.com/ show up
correctly as a 2x2 grid (instead of 1x4). :^)
If there are min or max size constraints in the cross axis for a flex
item that has a desired aspect ratio, we may need to adjust the main
size *after* applying the cross size constraints.
All the steps to achieving this aren't mentioned in the spec, but it
seems that all other browsers behave this way, so we should too.
If the parent BFC can come up with a nice stretch-fit width for the flex
container, it will have already done so *before* even entering flex
layout. There's no need to do it again, midway through the flex layout
algorithm.
This wasn't just unnecessary, but we were also doing it incorrectly and
not taking margins into account when calculating the amount of available
space for stretch-fit. This led to oversized flex containers in the
presence of negative margins.
Fixes#18614
This patch does three things:
- Factors out the code that determines whether a box will create a new
formatting context for its children (and which type of context)
- Uses that code to mark all formatting context roots in layout tree
dumps. This makes it much easier to follow along with layout since
you can now see exactly where control is transferred to a new
formatting context.
- Rebaselines all existing layout tests, since the output format has
changed slightly.
Although the spec doesn't mention it, if a flex item has box-sizing:
border-box, and the specified size suggestion is a definite size, we
have to subtract the borders and padding from the size before using it.
This fixes an issue seen in "This Week in Ladybird #4" where the
screenshots ended up in one long vertical stack instead of paired up
2 by 2.
When sizing a flex container with flex-direction:column under a
max-content height constraint, we were incorrectly truncating the
infinite available height to 0 when collecting flex items into lines.
This caused us to put every flex item in its own flex line, which is the
complete opposite of what we want during max-content intrinsic sizing,
as the layout would grow wide but not tall.
This isn't actually part of CSS-FLEXBOX-1, but all major engines honor
these properties in flex layout, and it's widely used on the web.
There's a bug open against the flexbox spec where fantasai says the
algorithm will be updated in CSS-FLEXBOX-2:
https://github.com/w3c/csswg-drafts/issues/2336
I've added comments to all the places where we adjust calculations for
gaps with "CSS-FLEXBOX-2" so we can find them easily. When that spec
becomes available, we can add proper spec links.
