This property represents the CSS content size, so let's reduce ambiguity
by using the spec terminology.
We also bring a bunch of related functions along for the ride.
Most of the time, we cannot resolve a `calc()` expression until we go to
use it. Since any `<length-percentage>` can legally be a `calc
()`, let's store it in `LengthPercentage` rather than make every single
user care about this distinction.
Despite looking like it was still needed, it was only used for passing
to other calls to Length::resolved() recursively. This makes the
various `foo.resolved().resolved()` calls a lot less awkward.
(Though, still quite awkward.)
I think we'd need to separate calculated lengths out to properly tidy
these calls up, but one yak at a time. :^)
A lot of this is quite ugly, but it should only be so until I remove
Length::Type::Percentage entirely. (Which should happen later in this
PR, otherwise, yell at me!) For now, a lot of things have to be
resolved twice, first from a LengthPercentage to a Length, and then
from a Length to a pixel one.
The flexbox logic confuses me so regressions are possible, though our
test page looks the same as before so it should be fine.
Renamed FlexBasis::Length -> LengthPercentage too, for clarity.
This was a hack to percentages within tables relative to the nearest
table-row ancestor instead of the nearest table container.
That didn't actually make sense, so this patch simply removes the hack
in favor of containing_block()->width().
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.
