Browsers such as Chrome and Firefox apply an arbitrary scale to the
current font size if `normal` is used for `line-height`. Firefox uses
1.2 while Chrome uses 1.15. Let's go with the latter for now, it's
relatively easy to change if we ever want to go back on that decision.
This also requires updating the expectations for a lot of layout tests.
The upside of this is that it's a bit easier to compare our layout
results to other browsers', especially Chrome.
It's safe to remove this pointer because intrinsic layout should never
look up a box's state beyond its containing block.
This change affects the expectations of two layout tests, but both
already differ slightly from other browsers, and the difference between
expectations is less than 5px.
With this change we no longer stretch "width: auto" for replaced
elements and also use "width calculation rules for block-level replaced
elements", like suggested by the spec.
Instead of directly invoking `to_px()`,
`calculate_min_content_contribution()` needs to use
`calculate_inner_width()` and `calculate_inner_height()`, which are
aware of how to correctly handle `min-content` and `max-content` values.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/3469
This fixes an issue where CSS vertical-align on a table-cell box would
incorrectly apply to both the table-cell box and any inline content it
had inside.
By the time we're measuring the height of a BFC root, we've already
collapsed all relevant margins for the root and its descendants.
Given this, we should simply use 0 (relative to the BFC root) as the
lowest block axis coordinate (i.e Y value) for the margin edges.
This fixes a long-standing issue where BFC roots were sometimes not tall
enough to contain their children due to margins.
This improves the quality of our font rendering, especially when
animations are involved. Relevant changes:
* Skia fonts have their subpixel flag set, which means that individual
glyphs are rendered at subpixel offsets causing glyph runs as a
whole to look better.
* Fragment offsets are no longer rounded to whole device pixels, and
instead the floating point offset is kept. This allows us to pass
through the floating point baseline position all the way to the Skia
calls, which already expected that to be a float position.
The `scrollable-contains-table.html` ref test needed different table
headings since they would slightly inflate the column size in the test
file, but not the reference.
compute_inset() was incorrectly retrieving the containing block size
because containing_block() is unaware of grid areas that form a
containing block for grid items but do not exist in the layout tree.
With this change, we explicitly pass the containing block into
compute_inset(), allowing it to correctly provide the containing block
sizes for grid items.
- Include vertical border spacing in row group offset calculation so
that they are axis-aligned with child row/cell elements. This makes it
so there isn't horizontal and vertical overflow caused by child
row/cell elements.
- Include horizontal border spacing in tr width calculations. This makes
it so tr elements don't have overflow anymore when there are multiple
columns.
- Apply vertical caption offset to row group top offset.
- Don't double-count top padding when calculating vertical offset for
tr and row groups.
- Add support for placement of abspos items into track formed by last
line and padding edge of grid container
- Correctly handle auto-positioned abspos items by placing them between
padding edges of grid container
Fixes crashing on https://wpt.live/css/css-grid/abspos/positioned-grid-descendants-001.html
..and delay static position calculation in IFC until trailing
whitespace are removed, because otherwise it's not possible to correctly
calculate x offset.
Containing block for abspos grid items depends on their grid placement:
- if element has definite grid position, then corresponding grid area
should be used as a containing block
- if element does not have definite grid position, then padding edge of
grid container should be used as a containing block
So offset should be adjusted for paddings only for boxes without
definite grid position.
The `calculate_inner_width()` and `calculate_inner_height()` resolve
percentage paddings using the width returned by
`containing_block_width_for()`. However, this function does not account
for grids where the containing block is defined by the grid area to
which an item belongs.
This change fixes the issue by modifying `calculate_inner_width()` and
`calculate_inner_height()` to use the already resolved paddings from the
layout state. Corresponding changes ensure that paddings are resolved
and saved in the state before box-sizing is handled.
As a side effect, this change also improves abspos layout for BFC where
now paddings are resolved using padding box of containing block instead
of content box of containing block.
Fixes yet another case of GFC bug, where Node::containing_block() should
not be used for grid items, because their containing block is grid area
which is not represented in layout tree.
Although the parameter is named "available size," it is always supposed
to represent the containing block size whenever it has a definite value.
Therefore, it is possible to simply use this value instead of performing
a containing block lookup.
This change actually improves correctness for grid items whose
containing block is defined by the grid area, as
`Node::containing_block()` does not account for this.
Change try_compute_width() to check whether min-width/max-width or width
is auto instead of always using `computed_values.width()`.
`grid/min-max-content.html` test is affected but it's progression.
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.
Fixes implementation of the following line from the spec:
"However, limit the growth of any fit-content() tracks by their
fit-content() argument."
Now we correctly apply a limit to increased growth limit rather than to
the planned increase.
Change in "Tests/LibWeb/Layout/input/grid/fit-content-2.html" is a
progression and "Item as wide as the content." is actually as wide as a
content.
When deciding if the grid containers min size should be limited by a
max size. Check for a max height or width depending on the dimension,
instead of just always checking for a max width.
Implements:
"If the product of the hypothetical fr size and a flexible track’s flex
factor is less than the track’s base size, restart this algorithm
treating all such tracks as inflexible."
Fixes https://github.com/LadybirdBrowser/ladybird/issues/1211
According to https://www.w3.org/TR/css-grid-2/#placement-shorthands
when setting the 'grid-row' and 'grid-column' shorthand property to a
single <custom-ident> value, both 'grid-row-start'/'grid-column-start'
and 'grid-row-end'/'grid-column-end' should be set to that
<custom_ident>.
Areas are disassembled into boundary lines on `build_grid_areas()` step,
so we can always use them to find grid item's position during placement.
This way we support both ways to define area: `grid-template-areas` and
implicitly using `-start` and `-end` boundary line names.
- Change min track sizing function to be "auto" when flex size is
specified.
- Never check if min track sizing funciton is flexible, because only
max is allowed to be flexible.
- Address FIXME in automatic_minimum_size to avoid regressions after
making two fixes mentioned above.
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.
Before this change, we only considering `grid-auto-flow` to determine
whether a row or column should be added when there was not enough space
in the implicit grid to fit the next unplaced item.
Now, we also choose the direction in which the "auto placement cursor"
is moved, based on the auto flow property.
With this change "max-width: max-content" is treated as "none" when
the available width is also "max-content". This fix prevents a stack
overflow in the grid track size maximization algorithm by avoiding
recursive calls to calculate_max_width() when determining the maximum
grid container size.
Now, we will evenly distribute the remaining free space across tracks
using the auto max-tracks sizing function, exactly as the specification
states. Many tests are affected, but they are not visually broken.
Fixes https://github.com/SerenityOS/serenity/issues/22798
This is a part of refactoring towards making the paintable tree
independent of the layout tree. Now, instead of transferring text
fragments from the layout tree to the paintable tree during the layout
commit phase, we allocate separate PaintableFragments that contain only
the information necessary for painting. Doing this also allows us to
get rid LineBoxes, as they are used only during layout.
