This fixes an issue where e.g `height: 100%` on a flex item whose
container has indefinite height was being resolved to 0. It now
correctly behaves the same as auto.
Previously, when having inline contexts consisting of just a `<br/>`
tag, we would not create a line box.
Ensure that there is always a line box when a line is explicitly being
broken and also ensure it won't be trimmed due to being empty.
This will a fix a number of sites that use `<br>` tags for layouts
between block elements (even though the spec says they shouldn't).
The image made the test flaky when running on my machine, so this
doesn't seem safe at the moment. We can just hardcode the dimensions.
Eventually we should make it possible to use external images in tests,
but for now let's not flake up the CI.
According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic
inlines should be layed out in a line box based on their margin box.
However, up until this patch we were unconditionally considering only
the border box during line box height calculation. This made us
essentially drop all vertical margins for atomic inlines.
Percentage line-height values are relative to 1em (i.e the font-size
of the element). We have to resolve their computed values before
proceeding with inheritance.
If normal flow layout has caused us to progress past the current
innermost float in the block axis, we still need to consider the floats
stacked outside of it.
Fix this by always walking the currently stacked floats from innermost
to outermost when placing new floats.
When using the flex shrink factor, the flexible length resolution
algorithm was incorrectly ignoring the `frozen` flag on items and would
update the same items again, causing overconsumption of the remaining
free space on the flex line.
In case flex items had `margin: auto` on the primary flex axis, we were
still also distributing remaining space according to `justify-content`
rules. This lead to duplicated spacing in various places and overflows.
It looks like this issue was observed previously but missidentified
because there was logic to ignore margins at the start and end which
would partially paper over the root cause. However this created other
bugs (like for example not having a margin at beginning and end ;-)) and
I can find nothing in the spec or other browser behaviour that indicates
that this is something that should be done.
Now we skip justify-content space distribution alltogether if it has
already been distributed to auto margins.
The draft CSS-FLEXBOX-1 spec had a more detailed description of this
algorithm, so let's use that as our basis for the implementation.
Test by Aliaksandr. :^)
When resolving these constraints to CSS pixel sizes, we have to resolve
padding-top and padding-bottom against the flex container's *width*,
not its height.
The padding-top and padding-bottom properties are relative to the
*width* of the containing block, not the height.
It's funny how we keep making this same mistake again and again. :^)
The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
If a box has clearance and margin bottom of preceding box is greater
than static y of the box then it should also affect y offset in current
block container so subsequent boxes will get correct y position too.
Though table wrappers are anonymous block containers (because
TableWrapper is inherited from BlockContainer) with no lines they
should not be skipped in block auto height calculation.
The current config on GitHub Actions does not use ccache, so it takes
quite a while to build. Instead, let's just run these tests on Azure
where we already build Ladybird and have ccache enabled. This also lets
us sanitize LibWeb on both Linux and macOS.
The script changes here are to A) handle differences between Azure and
GitHub Actions and B) to support running on macOS.
