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 css-sizing-3:
Additionally, the size of the containing block of an absolutely
positioned element is always definite with respect to that element.
As I understand this, it doesn't mean that all absolutely positioned
boxes have definite size, but that the containing block of an absolutely
positioned descendant has definite size from the perspective of the
descendant.
When computing whether whitespace should be collapsed or not, we have to
consider empty fragments, since <br> will produce an empty fragment to
force a line break.
LineBox::is_empty_or_ends_in_whitespace() is amended to look at the
length of the last fragment, and return true if it is 0.
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.
List item markers will never have children, so let's mark them as such,
which now allows our layout system to skip over their "insides" and
going straight to positioning instead.
Some boxes cannot have children (most commonly replaced elements),
and so there is nothing meaningful inside them to layout.
We now use the can_have_children() flag to quickly skip over such boxes
instead of creating a formatting context and other pointless busywork.
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.
The CSS spec uses the name "block formatting context root" when talking
about a box that establishes a BFC. So let's call it BFC::root() in our
code as well, instead of the less specific BFC::context_box().
Until now, we've internally thought of the CSS "display" property as a
single-value property. In practice, "display" is a much more complex
property that comes in a number of configurations.
The most interesting one is the two-part format that describes the
outside and inside behavior of a box. Switching our own internal
representation towards this model will allow for much cleaner
abstractions around layout and the various formatting contexts.
Note that we don't *parse* two-part "display" yet, this is only about
changing the internal representation of the property.
Spec: https://drafts.csswg.org/css-display
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.
This does a few things, that are hard to separate. For a while now, it's
been confuzing what `StyleValue::is_foo()` actually means. It sometimes
was used to check the type, and sometimes to see if it could return a
certain value type. The new naming scheme is:
- `is_length()` - is it a LengthStyleValue?
- `as_length()` - casts it to LengthStyleValue
- `has_length()` - can it return a Length?
- `to_length()` - gets the internal value out (eg, Length)
This also means, no more `static_cast<LengthStyleValue const&>(*this)`
stuff when dealing with StyleValues. :^)
Hopefully this will be a bit clearer going forward. There are lots of
places using the original methods, so I'll be going through them to
hopefully catch any issues.
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.
Negative margins are a headache anyways, and allowing them to be
negative lead to weird behavior.
This patch avoids vasty wrong height-calculations by limiting the
allowed margins to positive numbers when evaluating the height of a
block.
This fixes the issue where an `<img>` set to its native size would
sometimes still appear blurry, because it had a fractional position,
causing `enclosing_int_rect()` to expand by 1px.
