Before this change we always returned the font's point size as the
x-height which was basically never correct.
We now get it from the OS/2 table (if one with version >= 2 is available
in the file). Otherwise we fall back to using the ascent of the 'x'
glyph. Most fonts appear to have a sufficiently modern OS/2 table.
The specification isn't explicit about it, but the contribution we
compute should be distributed to all columns, not just the first one.
The first reason for it is symmetry, it doesn't make sense for the
increased width of the spanning column to only affect the first column
in the span.
The second reason is the formula for the cell contribution, which is
weighted by the non-spanning width of the cell relative to the total
width of the columns in the same row. This only covers a fraction of the
gap, in order to fully cover it we have to add it to all columns in the
span. For this to be exactly the case when the columns don't all have
the same width, we'd have to add additional weighting based on the width
ratios, but given that the specification doesn't suggest it at all we'll
leave it out for now.
Change the name and return type of
`IPv6Address::to_deprecated_string()` to `IPv6Address::to_string()`
with return type `ErrorOr<String>`.
It will now propagate errors that occur when writing to the
StringBuilder.
There are two users of `to_deprecated_string()` that now use
`to_string()`:
1. `Formatted<IPv6Address>`: it now propagates errors.
2. `inet_ntop`: it now sets errno to ENOMEM and returns.
Calculate a "preferred aspect ratio" based on the value of
`aspect-ratio` and the presence of a natural aspect ratio, and use that
in layout.
This is by no means complete or perfect, but we do now apply the given
aspect-ratio to things.
The spec is a bit vague, just saying to calculate sizes for
aspect-ratio'ed boxes the same as you would for replaced elements. My
naive solution here is to find everywhere we were checking for a
ReplacedBox, and then also accept a regular Box with a preferred aspect
ratio. This gets us pretty far. :^)
https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all
implemented.
These are superseded by headless-browser running these tests in a single
process, and aren't used by CI anymore. It's a bit confusing having them
still around so let's be rid of them.
I opened smolkling.webp in Photoshop, added a layer mask with a vertical
gradient, replaced the leftmost column with completely transparent
pixels (because the leftmost column is vertically predicted with the
horizontal filter too), and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling.webp \
-o Tests/LibGfx/test-inputs/smolkling-vertical-alpha.webp
That did the trick.
I opened smolkling.webp in Photoshop, added a layer mask, and
scribbled a shape vaguely looking like the letter "C" on it.
I then saved it as a lossy webp and that was enough to end up
with filter method ¯\_(ツ)_/¯
I opened smolkling.webp in Photoshop, added a layer mask with a
horizontal gradient, and saved it as webp. That wasn't enough to
get a horizontal filter for the ALPH chunk though, so I also ran
cwebp \
-alpha_filter best \
smolkling-ps.webp \
-o Tests/LibGfx/test-inputs/smolkling-horizontal-alpha.webp
That did the trick.
(Looks like doing the same with a vertical or diagonal gradient
_also_ produces a webp file with filtering_method 1, i.e. horizontal.)
Prior to this commit, PropertyOwningCSSStyleDeclaration::serialized()
did not include custom properties, which lead to an incomplete
`cssRule.cssText` result.
This commit makes that class also serialize the custom properties and
place them before the regular properties in the rule text.
On macOS, CMake incorrectly tries to add and/or remove rpaths from files
that it has already processed when it performs installation. Setting the
rpaths during the build process ensures that they are only set once, and
as a bonus, makes installation slightly more performant.
Fixes#10055.
We were incorrectly returning a "specified size suggestion" for flex
items with a definite main size where that main size was also automatic.
This led to us incorrectly choosing 0 as the automatic minimum size for
that flex item, instead of its min-content size.
Generated iterator prototypes already have the IteratorPrototype as
their prototype, but we were incorrectly hijacking them and rerouting
to ObjectPrototype.
Regressed in cfe663435e.
The main differences between our current implementation and the spec
are:
* The title element need not be a child of the head element.
* If the title element does not exist, the default value should be
the empty string - we currently return a null string.
* We've since added AOs for several of the spec steps here, so we
do not need to implement those steps inline.
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 fixes the issue that currently we use "auto" as initial value for
grid-template-column and grid-template-rows although spec says it
should be "none". This makes a lot of difference for these properties
because currently we represent "auto" as a list with one auto-sized
track which means initial value for grid-template-column defines one
"explicit" track while it should define none of them.
This change makes grid-auto-columns/rows be applied to the correct
tracks when initial values is used for grid-template-column/rows.
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.
Depending on stack values being correctly and deterministically
overwritten was a bit too optimistic, to be honest. This new logic uses
a value on the heap.
Dr. POSIX says:
Although the space used by string is no longer used once a new
string which defines name is passed to putenv(), if any thread in
the application has used getenv() to retrieve a pointer to this
variable, it should not be freed by calling free(). If the changed
environment variable is one known by the system (such as the locale
environment variables) the application should never free the buffer
used by earlier calls to putenv() for the same variable.
Applications _should_ not free the data passed to `putenv`, but they
_could_ in practice. I found that our Quake II port misbehaves in this
way, but does not crash on other platforms because glibc/musl `putenv`
does not assume that environment variables are correctly formatted.
The new behavior ignores environment variables without a '=' present,
and prevents excessively reading beyond the variable's name if the data
pointed to by the environment entry does not contain any null bytes.
With this change, our Quake II port no longer crashes when switching
from fullscreen to windowed mode.
This fixes an issue where images with padding and/or border did not have
their size adjusted for `border-box`, thereby becoming larger than
intended by the author.
I was not aware of this framework back when implementing this back in
bc54560e59. Add in some basic tests for
this now that we are compliant with the specification.
If a box has a negative margin-left, it may have a negative effective
offset within its parent BFC root coordinate system.
We can account for this when calculating the amount of left-side float
intrusion by flooring the X offset at 0.
Now that we have a way to resolve calc() lengths without a layout node,
we can finally support calc() values in font-size.
This wasn't possible before because font-related properties have to be
resolved eagerly in StyleComputer due to font-relative CSS length units
depending on the computed font being known.
Use contains_percentage() that works for calc() values instead of
is_percentage().
This fixes issue when tracks with calc() that has percentages where
considered as "fixed" tracks with resolvable size which led to
incorrectly resolved infinite final track sizes.
This reintroduces bounds-checking for the CSS `<angle>`, `<frequency>`,
`<integer>`, `<length>`, `<number>`, `<percentage>`, `<resolution>`,
and `<time>` types.
I regressed this around 6b8f484114 when
changing how we parsed StyleValues.
This is an improvement from before though, since we now allow the bounds
of a dimension type to have units.
Added a test to make sure we don't regress this again. :^)
If a flex item's main size is a CSS calc() value that resolves to a
length and contains a percentage, we can only resolve it when we have
the corresponding reference size for the containing block.
Previously, we would always respect the `text-align` property, even if
the text being aligned was too long for its line box and would be
clipped. This led to seeing the clipped middle/end of strings when we
should instead always see the beginning of the text.
In AArch CI, this test alone takes up 110.6 seconds. In x86_64 CI, it
takes up 68.4 seconds. There is no reason to spend this much time and
this many trials on this.
Let's reduce the number of iterations to 500. This should still surface
any misalignment with high probability, and should speed up the CI time
from minutes to seconds.
This is a hack to emulate the behavior of other engines that use
fixed-point math. By rounding to 3 decimals, we retain a fair amount of
detail, while still allowing overshooting 100% without breaking lines.
This is both gross and slow, but it fixes real sites. Notably, the
popular Bootstrap library uses overshooting percentages in their
12-column grid system.
This hack can be removed when CSSPixels is made a fixed-point type.
