If the first pass of rows sizing results in the container's automatic
height being less than the specified min-height, we need to run a
second pass using the updated available space.
Previously this didn't cause issues because the default flex-factor is
0, but once we only store a flex-factor for FlexibleLength-type
GridSizes, this causes a crash.
This also adds some additional operators to `CSSPixelsFraction` to
allow this change to build, since some places were using equations like
`(a / b) + (c / d)` or `-(x / y)`.
Previously, the code assumed that in dividing up the space in the
affected tracks there would never be an overshoot. Instead, we can
check for each track how much extra space is left and never consume any
extra.
In the same way, we can ensure that all extra space is consumed by
distributing all remaining extra space starting from the first track.
Thus, if there is no growth limit, the space distribution should always
consume all the extra space.
The spec says that the sum of affected size + item-incurred increase
should reach the limit, rather than just the item-incurred increase.
This seems to improve layout on the testcase `row-span-2-with-gaps`.
The extra line of space at the bottom of the left div
(`div.grid-item.item-span-two`) is not present anymore, matching other
browsers' layout much more closely.
We need to start looking from the beginning of current row if adding
new implicit column track made enough space to accomodate spanning item
This fixes placement for spanning grid items when `grid-auto-flow` is
specified to `column`.
When the grid layout gets to
`resolve_items_box_metrics(GridDimension::Column)`, we've already
determined the width of each column. However, the widths of the
individual grid items themselves haven't been set. Rather than using
`get_available_space_for_item()`, which returns an indefinite size if
an item's width/height hasn't been set, we should use the already
known track width as the available size to calculate the fit-content
width.
This is intended to annotate conversions from unknown floating-point
values to CSSPixels, and make it more obvious the fp value will be
rounded to the nearest fixed-point value.
In general it is not safe to convert any arbitrary floating-point value
to CSSPixels. CSSPixels has a resolution of 0.015625, which for small
values (e.g. scale factors between 0 and 1), can produce bad results
if converted to CSSPixels then scaled back up. In the worst case values
can underflow to zero and produce incorrect results.
- Ambiguous `raw_value()` method is replaced with `line_number()` and
`span()`.
- `line_name()` that before returned either line name or area name is
replaced with `line_name()` and `area_name()`.
- `Position` type is replaced with `Line` and `Area` type so we don't
have to guess while doing layout.
Affected test expectations:
- `template-lines-and-areas` - improvement over what we had before.
- `named-tracks` - rebaseline a giant test. will have to split it into
smaller tests in the future.
Changing `calculate_min_content_heigh()` and
`calculate_min_content_heigh()` to accept width as `CSSPixels`, instead
of `AvailableSize` that might be indefinite, makes it more explicit
that width is supposed to be known by the time height is measured.
This change has a bit of collateral damage which is rows height
calculation regression in `table/inline-table-width` that worked before
by accident.
- Out-of-flow items should not affect grid layout
- "The static position of an absolutely-positioned child of a grid
container is determined as if it were the sole grid item in a grid
area whose edges coincide with the content edges of the grid
container."
Fixes infinite spinning in the cases when CSSPixels does not have
enough precision to represent increase per track which happens when
very small extra_space got divided by affected tracks number.
Fixes the issue that before "automatic minimum size" were used to size
flexible tracks even though specification says is should be "minimum
contribution"
In c66dbc99ee GFC was updated to use -1
as special value for the infinite growth limit. However, using Optional
instead reduces the risk of accidentally using -1 special value in
layout calculations.
Using fixed-point saturated arithmetics for CSSPixels allows to avoid
accumulating floating-point errors.
This implementation is not complete yet: currently saturated
arithmetics implemented only for addition. But it is enough to not
regress any of layout tests we have :)
See https://github.com/SerenityOS/serenity/issues/18566
This is the preparation to use fixed-point to represent CSSPixels.
Previously, it was acceptable to divide CSSPixels by zero, resulting
in inf, but after migrating to fixed-point stored as an integer, it
would lead to undefined behavior.
This is preparation for introducing fixed-point CSSPixels in upcoming
commits.
Infinity is a valid state for the growth limit value of a grid track.
It was possible to use INFINITY when CSSPixels were represented using
floating point, but it won't work after the transition to fixed point,
which is represented using integers. This change addresses this by
using -1 as a special value to represent the infinite state of the
growth limit.
This change implements following paragraph from placement algorithm in
the spec:
"If the largest column span among all the items without a definite
column position is larger than the width of the implicit grid, add
columns to the end of the implicit grid to accommodate that column
span."
There were places in the grid implementation code with copies of this
text, but those were completely unrelated to the code where they were
being pasted so I removed them.
Although DistinctNumeric, which is supposed to abstract the underlying
type, was used to represent CSSPixels, we have a whole bunch of places
in the layout code that assume CSSPixels::value() returns a
floating-point type. This assumption makes it difficult to replace the
underlying type in CSSPixels with a non-floating type.
To make it easier to transition CSSPixels to fixed-point math, one step
we can take is to prevent access to the underlying type using value()
and instead use explicit conversions with the to_float(), to_double(),
and to_int() methods.
Adds a second pass to resolve percentage paddings and margins of grid
items after track sizes are known. If resolving percentage paddings
or margins affects tracks sizes then second pass to re-resolve track
sizes might also be needed but I cannot come up with an example to
reproduce that so we can leave it to improve in the future :)
This fixes the issue when functions that distribute base_size
or growth_limit to tracks only considered *affected* spanned tracks
while calculating left extra that is available for distribution while
indeed it should be just *all* spanned track by specific item that
extra space size.
This changes grid items position storage type from unsigned to signed
integer so it can represent negative offsets and also updates placement
for grid items with specified column to correctly handle negative
offsets.
Fixes the bug that currently we always consider tracks with percentage
size as ones with "fixed" length even when available size is not
definite. With this change tracks with percentage size when available
size is not definite will be considered as "intrinsic" sized.
