I couldn't find anything in the specs about this, but GMail uses
empty generated boxes (`::before` and `::after` with `content: ""`)
inside a flexbox container in order to vertically center things.
The flexbox spec tells us to not generate flex items for empty
*anonymous* boxes, so we continue not doing that, but generated boxes
(any pseudo-element box) now always produce a flex item. This probably
isn't perfect either, and we'll have to revisit it for stuff like
`::first-letter`.
Let's not assume the containing block has a paintable box just because
someone is calling set_needs_display(). It can just be a no-op in that
case, and nobody gets hurt.
Instead of formatting contexts flailing around to figure out from the
"inside" how much space is available on the "outside", we should
provide the amount of available space in both axes as an input to run().
This basically means that when something creates a nested formatting
context, the parent context is responsible for telling the nested context
how much space is available for layout. This information is provided
immediately when invoking run().
Note that this commit doesn't pass accurate values in all cases yet.
This first step just makes it build, and passes available values in some
cases where getting them was trivial.
This patch changes the *computed* representation of the following CSS
properties to use CSS::Size:
- width, min-width, max-width
- height, min-height, max-height
A few things had to change in order for things to keep working,
but I tried to keep the diff to a minimum.
The main trouble was that `min-width` and `max-width` can't actually be
`auto`, but they *can* be `none`. We previously treated `auto` as a
valid value (and it behaved mostly like `none`).
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.
