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.
Values that contain percentages require special treatment in various
parts of layout. Previously we had no way of peeking into calc() values
to see if their expression contains one or more percentages. That's the
bulk of what we're adding here.
This partially adds serialization code for
`CSSFontFaceRule::serialized()` to spec. This is only partially
implemented as some parts of the `@font-face` rule are not implemented
yet.
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.
Often in the spec they talk about intrinsic_track_sizes and this way can
have a clearer way of checking if a GridTrackSize is indeed an
"intrinsic track size".
Makes it more convenient to create auto GridTrackSizes. I think having
an auto GridTrackSize be defined by an auto Length value kind of
confusing, and this at least helps when creating one.
To follow spec more closely, only set the has_span value if there is a
number immediately following, like "span 2". Otherwise the span value
should be ignored.
Use float instead of int for the GridTrackSize length value as
FlexibleLengths can be "1fr" as well as ".49fr" in grid-track-row
and grid-track-column values.
With 6 bits of precision, the maximum triangle coordinate we can
handle is sqrt(2^31 / (1 << 6)^2) = ~724. Rendering to a target of
800x600 or higher quickly becomes a mess because of integer overflow.
By reducing the subpixel precision to 4 bits, we support coordinates up
to ~2896, which means that we can (try to) render to target sizes like
2560x1440.
This fixes the main menu backdrop for the Half-Life port. It also
introduces more white pixel artifacts in Quake's water / lava
rendering, but this is a level geometry visualization bug (see
`r_novis`).
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.
Not visiting the field holding SubtleCrypto in Crypto caused subtle
crashes all over the Value functions, due to accessing SubtleCrypto
after it was garbage collected (and potentially replaced by a new cell).
This meant that the crashes were only appearing in Value::to_boolean,
Value::typeof, etc. Which then held pointer to things that looked like
Shapes, Environments and other non-Object Cells.
To find the actual cause, all pointer used to construct Values were
checked and if a pointer was none of the allowed types, the backtrace
is logged.
Co-authored-by: Luke Wilde <lukew@serenityos.org>
Previously we would constrain the unicode block list to a width of 175,
causing it to stick to the splitter when manually resizing.
This patch allows resizing the list properly while retaining the new
width when resizing the window.
Up until now, we have only dealt with games that pass Q = 1 for their
texture coordinates. PrBoom+, however, relies on proper homogenous
texture coordinates for its relatively complex sky rendering, which
means that we should perform this per-fragment division.
