When the flex container is sized under a min-content constraint in the
main axis, any flex items with a percentage main size should collapse
to zero width, not take up their own intrinsic min-content size.
This is not in the spec, but matches how other browsers behave.
Fixes an issue where the cartoons on https://basecamp.com/ were way
too large. :^)
Before this change, a formatting context was responsible for layout of
absolutely positioned boxes whose FC root box was their parent (either
directly or indirectly). This only worked correctly when the containing
block of the absolutely positioned child did not escape the FC root.
This is because the width and height of an absolutely positioned box are
resolved based on the size of its containing block, so we needed to
ensure that the containing block's layout was completed before laying
out an absolutely positioned box.
With this change, the layout of absolutely positioned boxes is delayed
until the FC responsible for the containing block's layout is complete.
This has affected the way we calculate the static position. It is no
longer possible to ask the FC for a box's static position, as this FC's
state might be gone by the time the layout for absolutely positioned
elements occurs. Instead, the "static position rectangle" (a concept
from the spec) is saved in the layout state, along with information on
how to align the box within this rectangle when its width and height are
resolved.
When determining the intrinsic cross size contribution of a flex item
with a preferred aspect ratio, we have to account for any min/max
constraints in the main axis.
In calculating the base size of a flex item, we have a piece of ad-hoc
code that deals with an item that does have an instrinsic aspect ratio,
but not a cross size to resolve that ratio against. In determining the
actual flex item size however, we also take into account the minimum
content width and height, which assumes the box' intrinsic width or
height when available. This would break having an image as a flex item,
which gets stretched to its maximum size within the flex container
instead of the flex item being shrunk to the instrinsic size of the
image.
Fix this by only stretching flex items that do not have an instrinsic
width nor height set.
When traversing the layout tree to find an appropriate box child to
derive the baseline from. Only the child's margin and offset was being
applied. Now we sum each offset on the recursive call.
If a flex item has a preferred aspect ratio and the flex basis is not
definite, we were falling back to using stretch-fit for the main size,
since that appeared to match other browsers.
However, we missed the case where we actually have a definite cross size
through which the preferred aspect ratio can be naturally resolved.
There was no need to set an available height constraint when doing early
height calculation for inline-flex boxes. It created a situation where
the flex containers could wrongly get zero height early, and then
resolve percentages against zero instead of the real intrinsic size.
Fixes#23942
This solves a particular issue with SVG as flex items, where the SVG has
an intrinsic aspect ratio via its viewBox, but no explicit natural width
or height.
Makes all corporate sponsor logos show up on https://ziglang.org/ :^)
Height definiteness is now preserved as intended by CSS-SIZING-3
(assuming I've understood it correctly) and not implicitly granted by
layout algorithms when they assign height.
For the specific special/magical cases where some sizes become definite
during layout, the preceding commits have made them explicit in code.
This fixes a number of flex layout issues where we were previously
resolving percentage values against post-layout flex container heights,
but other browsers don't.
Before this change, it was possible for flex lines with negative
remaining space (due to overflowing items) to put a negative amount
of space between items for some values of `justify-content`.
This makes https://polar.sh/SerenityOS look much better :^)
There are a bunch of situations where we need to treat cross axis
max-size properties as "none", notably percentage values when the
reference containing block size is an intrinsic sizing constraint.
This fixes an issue where flex items with definite width would get
shrunk to 0px by "max-width: 100%" in case the item itself is an
SVG with no natural width or height.
For consistency, we now use the should_treat_max_width/height_as_none
helpers throughout FFC.
This makes the search/account/cart icons show up in the top right
on https://twinings.co.uk :^)
Before this change, we used the wrong insertion point for flex items
in reverse layouts with `justify-content: normal`. This caused flex
items to overflow the flex containers "backwards" from the start edge.
CSSPixels should not be wrapped into CSS::Length before being passed
to resolved() to end up resolving percentages without losing
precision.
Fixes thrashing layout when 33.3333% width is used together with
"box-sizing: border-box".
We were incorrectly offsetting the static position of abspos children of
flex containers by the padding twice. This was a misguided attempt to
adjust to the abspos containing block being the padding box, not the
content box.
Fixes#21344.
There's a particularly awkward case where the static position of an
abspos child of a flex container is dependent on its height. This can
happen when `align-items: center` is in effect, as we have to adjust
the abspos child's Y position by half of its height.
This patch solves the issue by reordering operations in the abspos
height resolution algorithm, to make sure that height is resolved
before the static position is calculated.
Before this change, we were creating a new anonymous flex item for every
inline-level child of a flex container, even when we had a sequence of
inline-level children.
The fix here is to simply keep putting things in the last child of the
flex container, if that child is already an anonymous flex item.
CSS-ALIGN-3 tells us that `normal` behavior inside flex containers is
simply to behave as `stretch` so this patch makes them behave the same
inside FFC.
Furthermore, we change the `align-items` initial value to `normal`,
matching other engines.
This stuff is pretty hairy since the specifications don't give any
guidance on which widths to use when calculating the intrinsic height of
flex items in a column layout.
However, our old behavior of "treat anything indefinite as fit-content"
was definitely not good enough, so this patch improves the situation by
considering values like `min-content`, `max-content` and `fit-content`
separately from `auto`, and making the whole flex layout pipeline aware
of them (in the cross axis context).
Properties like min-width, max-width, etc, should be ignored while we're
trying to determine the intrinsic size of a flex container.
This fixes an infinite recursion when using an intrinsic size keyword as
the max-width of a flex column container.
Note that this behavior is marked as AD-HOC in code comments because
specs don't tell us how to achieve intrinsic sizing.
We can now load product pages on the Twinings site, such as
https://twinings.co.uk/products/earl-grey-100-tea-bags :^)
This change makes tree builder omit elements with "display: contents"
from the layout tree during construction. Their child elements are
instead directly appended to the parent element in layout tree.
Auto margins used together with justify-content would previously
result in children being positioned outside their parent. This was
solved by letting auto margins take precedence when they are used,
which was already implemented to some extent before, but not
fully.
After switching to fixed-point arithmetic in CSSPixels, it no longer
supports representing infinite values, which was previously the case
for remaining_free_space in FFC. Using Optional that is not empty only
when value is finite to store remaining_free_space ensures that
infinity is avoided in layout calculations.
Once we've resolved the used flex item width & height, we should allow
percentage flex item sizes to resolve against them instead of forcing
flex items to always treat percentages as auto while doing intrinsic
sizing layout.
Regressed in 8dd489da61.
We do this by piggybacking on FormattingContext helpers instead of
reinventing the wheel in FlexFormattingContext.
This fixes an issue where `min-width: fit-content` (and other
layout-dependent values) were treated as 0 on flex items.
This makes the cookie banners look okay on https://microsoft.com/ :^)
The tests still pass, but opening the files in Ladybird and Safari or
Firefox shows clearly where the layouting in Ladybird is incorrect
for some absolute positioned elements. The previous 1px border was
subtly hiding some issues.
When sizing under a max-content constraint, we allow flex lines to have
an infinite amount of "remaining space", but we shouldn't let infinity
leak into the geometry of items. So treat it as zero in arithmetic.
This fixes an issue where inline SVGs with natural aspect ratio (from
viewBox) but no natural width or height could get an infinite size as
flex items.
The part in FFC where we ask the parent formatting context to size the
flex container midway through layout is really weird, but let's at least
be consistently weird for BFC and IFC. Since IFC always works within its
parent BFC, it can simply forward these requests to the BFC.
This fixes an issue where inline-flex containers incorrectly had main
axis margins subtracted from their content size.
We were incorrectly returning a "specified size suggestion" for flex
items with a definite main size where that main size was also automatic.
This led to us incorrectly choosing 0 as the automatic minimum size for
that flex item, instead of its min-content size.
If a flex item's main size is a CSS calc() value that resolves to a
length and contains a percentage, we can only resolve it when we have
the corresponding reference size for the containing block.
If the flex container is being sized under a max-content main size
constraint, there is effectively infinite space available for flex
items. Thus, flex lines should be allowed to be infinitely long.
This is a little awkward, because the spec doesn't mention specifics
about how to resolve flexible lengths during intrninsic sizing.
I've marked the spec deviations with big "AD-HOC" comments.
We were not taking reverse flex directions into account when choosing
the initial offset for flex item placement if justify-content were
either space-around or space-between.
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). :^)
