Since FFC is only ever run() on the flex container, we can assume (but
verify) that the run box is the flex container and use an accessor
throughout. The end result: less parameter passing.
Determining the available main and cross space is now done by a separate
function. The signature is a little bit hairy since this function
computes some things that are used by subsequent algorithm steps.
Factoring can definitely be improved further.
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
Auto margins are still not supported at all, but this is a good start
into supporting margins on flex items.
The way cross-before (top for row, left for column) is handled is very
naive.
Previously, if the parent of the container had a definite main size, it
would've been disregarded when calculating the main size of the
container if it had no definite size and neither min- nor max-main-size
constraints.
This patch fixes that behavior by additionally checking whether the main
size is not only not constrained but also infinite.
A flex-basis of zero doesn't actually mean that the preferred size of
the particular Box is 0. It means that the Box should take the least
amount of space possible while still accomodating the content inside.
We catch and circumvent this now right when the flex-basis property gets
read for the FlexFormattingContext.
This isn't mentioned anywhere in the seemingly relevant portions of the
spec, however thanks to this answer https://stackoverflow.com/a/47579078
(which is not entirely correct about width either) lead to the behavior
that is wanted and used by other Browsers.
If an element has a relative specified length on the cross axis, but in
the lineage there are no parents that have any fixed cross size, this
would have resulted in a 0 cross size.
We now catch that and check whether the relative length would result in
an actual definite length if resolved.
Previously any children would be layout using a BlockFormattingContext.
Now we at least differentiate between IFC and BFC if the sizes in
question are not constrained by other things.
This is a hack, but it seems to do quite okay.
What we should do is to find the largest size the Box could want in its
main axis. To do that we have to layout the Box according to the needed
LayoutMode. For flex-rows we do as requested and try to make the Box as
wide as we want.
However, for flex-columns we simply assume the Box is a Block and we
calculate their height according to this.
If our parent in the FlexFormattingContext also was a flex-container, we
didn't give our children any meaningful width to play with into
layout_inside(), which resulted in way too narrow layouting.
Now the width of the parent gets borrowed if the own width isn't
specified.
This was an error in understanding what calculated_values are and that
those are not what is wanted when getting the main available size of the
box in the FlexFormattingContext.
The calculation around the size calculation is still a bit wonky, but
this is definietly better.
