This ends up having a big impact on performance, as we now correctly
treat a used flex-basis of `content` as `max-content` which means
we can use cacheable intrinsic sizes for flex items in the majority
of cases.
This was used by FFC to estimate the height of flex items after
performing layout inside them.
Now that we have automatic_content_height(), we no longer need this
awkward API and we can fold it into BFC's own height calculation.
This function should return the automatic height of the formatting
context's root box.
Until now, we've been relying on some magical handshakes between parent
and child context, when negotiating the height of child context root
boxes. This is a step towards something more reasonable.
We were forgetting to convert to and from BFC root relative coordinates
when calculating how much clearance was needed to get past floats.
This fixes the last remaining issue on Acid1, which is now perfect. :^)
Previously, we were using the full containing block width as a reference
for text-align values "right" and "center". This didn't take intruding
floats into account.
Layout box offset coordinates are always relative to their containing
block. Therefore, the functions that convert between coordinate spaces
should only visit containing blocks and apply their offsets, not *every*
box in the parent chain.
This fixes an issue where some floating boxes were unexpectedly far away
from their containing block.
We already had a helper for this, but compute_height() wasn't using it.
Tweak it so that compute_height() can use it, and remove the duplicated
code that's now redundant.
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibWeb/HTML/CrossOrigin/CrossOriginOpenerPolicy.h>
// That's it, this was enough to cause a compilation error.
Likewise for most other files touched by this commit.
The flex line cross size includes the margin boxes of items, so when
we're taking the flex line's cross size to use as an item cross size,
we have to subtract the margin, border padding from both sides.
Previous we only subtracted the cross margins, which led to oversized
items in some cases.
Instead of asking Gfx::FontDatabase for the "default font" and the
"default fixed-width font", we now proxy those requests out via
the Platform::FontPlugin. This will allow Ladybird to use other default
fonts as fallback.
This patch combines a number of techniques to make inline content flow
more correctly around floats:
- During inline layout, BFC now lets LineBuilder decide the Y coordinate
when inserting a new float. LineBuilder has more information about the
currently accumulated line, and can make better breaking decisions.
- When inserting a float on one side, and the top of the newly inserted
float is below the bottommost float on the opposite side, we now reset
the opposite side back to the start of that edge. This improves
breaking behavior between opposite-side floats.
- After inserting a float during inline layout, we now recalculate the
available space on the line, but don't adjust X offsets of already
existing fragments. This is handled by update_last_line() anyway,
so it was pointless busywork.
- When measuring whether a line can fit at a given Y coordinate, we now
consider both the top and bottom Y values of the line. This fixes an
issue where the bottom part of a line would bleed over other content
(since we had only checked that the top Y coordinate of that line
would fit.)
There are some pretty brain-dead algorithms in here that we need to make
smarter, but I didn't want to complicate this any further so I've left
FIXMEs about them instead.
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibWeb/CSS/GridTrackSize.h>
// That's it, this was enough to cause a compilation error.
When calculating the automatic height of a BFC root, we stretch it to
contain the bottommost margin edge of floating boxes.
Before this change, we assumed that floating boxes had coordinates
relative to the BFC root, when they're actually relative to the floating
box's containing block. This may or may not be the BFC root, so we have
to use margin_box_in_ancestor_coordinate_space() to apply offsets from
all boxes in the containing block chain (up to the BFC root).
This is rather subtle and points to our architecture around definite
sizes not being exactly right, but...
At some points during flexbox layout, the spec tells us that the sizes
of certain flex items are considered definite from this point on.
We implement this by marking each item's associated UsedValues as
"has-definite-width/height".
However, this breaks code that tries to resolve computed "auto" sizes
by taking the corresponding size from the containing block. The end
result was that the 1st sizing pass in flexbox would find the right size
for an "auto" sized item, but the 2nd pass would override the correct
size with the containing block's content size in that axis instead.
To work around the issue, FFC now remembers when it "definitizes" an
item, and future attempts to resolve an "auto" computed size for that
value will bypass the computed-auto-is-resolved-against-containing-block
step of the algorithm. It's not perfect, and we'll need to think more
about how to really represent these intermediate states relating to
box sizes being definite..
By asking if the value *contains* a percentage rather than whether it
*is* one, we cover many more cases where e.g `width: calc(100% - 10px)`
should be "treated as auto" etc.
Now that the positions of each grid item have been calculated, and the
sizes of the individual rows and columns ascertained, can actually
layout the different items.
According to the spec it's necessary to:
1. Layout the cells in the grid
2. Find the sizes of the rows and columns
Since I had started to do this backwards, and as I expand in future
commits, I take here the opportunity to start with a clean state.
The occupation_grid keeps track of which cells in the grid have been
filled out.
Before this change, we'd always insert one line box fragment, even when
a float was taking up too much space on the line, and the fragment
didn't actually fit.
We now perform line breaks until we have enough space between floats.
This fixes many page layouts where we'd previously see small fragments
of inline content outside the right edge of the containing block.
If the containing block has indefinite height, we can't resolve
percentage heights against it. Instead of treating it as 0 by accident,
let's treat it as "auto" on purpose.
This brings back the cheek borders on Acid2.
We didn't set their display at all before, and since CSS display is not
inherited, anonymous block wrappers were actually "display: inline", but
it kinda worked anyway because we positioned blocks based on their C++
class (BlockContainer) rather than their CSS display value.
Now that we position based on CSS display value, this broke positioning
of anonymous wrapper blocks, and this fixes that.
