When parsing declarations within a nested grouping rule, we don't store
these directly, but within a "nested declarations rule", in most cases
this is `CSSNestedDeclarations`, but this isn't always the case e.g.
`@function` rules and others (e.g. @media) within them should instead
use `CSSFunctionDeclarations`
Some at-rules (i.e. `@function`) require us to support custom
descriptors (e.g. `--foo`).
We do this by adding `DescriptorID::Custom` and using a new
`DescriptorNameAndID` class in a bunch of places where we previously
just used `DescriptorID`
Use Skia's SkTextBlob::getIntercepts() to find where glyph outlines
cross the underline/overline band, then split the decoration line into
segments with gaps around those intersections.
Previously we waited until used-value time to apply handling for the
z-index value that we should have applied at declared or computed-value
time, which was papered over by returning the used rather than computed
value as the resolved value. This is no longer required.
This allows us to unmark z-index as requiring a layout node to get
resolved value.
Currently this only applies to the `@property` `syntax` descriptor.
As with custom properties in the previous commit we assumed that any
consumed values were valid but that's not the case.
The definition of syntax in the "css-properties-values-api" spec (which
is used for the `@property/syntax` descriptor) is slightly different
from the definition of `<syntax>` in the "css-values" spec (which we
implement) in that it limits literal idents to exclusively
`<custom-ident>`s (i.e. not CSS-wide keywords or "default").
`<custom-ident>`s are also case-sensitive so that behavior is
implemented for syntax matching here as well
Previously we would consider an alternative syntax child to be a match
as long as parsing produced a value, even if there were trailing tokens
(which would later invalidate it within `parse_with_a_syntax`). This
meant that we wouldn't consider later alternatives which may actually
produce a valid match.
This requires us to front load computation of writing-mode and direction
before we encounter any logical aliases or their physical counterparts
so that we can create a mapping context.
Doing this at compute rather than cascade time achieves a few things:
1) Brings us into line with the spec
2) Avoids the double cascade that was previously required to compute
mapping contexts
3) We now compute values of logical aliases, while
`style_value_for_computed_property` maps logical aliases to their
physical counterparts, this didn't account for all cases (i.e. if
there was no layout node, Typed OM, etc).
4) Removes a hurdle to moving other upstream processes (i.e. arbitrary
substitution function resolution, custom property computation) to
compute time as the spec requires.
Pass the requested font weight and slope to generic_font_name() and use
them to select the most suitable font family. Families that have the
exact requested weight are strongly preferred, followed by families with
more style variety.
This ensures that when CSS requests bold text with a generic font family
like `serif`, we select a family that actually supports bold weights
rather than one that only has regular weight.
Co-authored-by: Jelle Raaijmakers <jelle@ladybird.org>
We no longer try to resolve calculated values at parse time which means
we support relative lengths.
We now clamp negative values rather than rejecting them at parse time.
Parsing has been inlined into `parse_ratio_value` and `parse_ratio` has
been removed since `parse_ratio_value` was the only caller
`accent-color` is the only user of the fallback functionality of
`color_or_fallback`, by handling this explicitly we can remove that
fallback functionality in a later commit.
Also includes a couple of improvements for `accent-color` specifically:
- We don't set it in `ComputedValues` twice.
- `ComputedProperties::accent_color` returns a non-optional value
(since we always have one)
- `ComputedProperties::accent_color` takes a `ColorResolutionContext`
instead of generating one itself from a `LayoutNode`, this will allow
us to reuse shared resolution contexts in the future
When parsing block contents, the CSS parser speculatively tries to parse
each item as a declaration first. If that fails, it restores the token
position and tries again as a qualified rule. This means every qualified
rule inside an at-rule block (e.g. @layer, @media) gets parsed twice:
once as a failed declaration (which consumes all tokens via
consume_the_remnants_of_a_bad_declaration), and then again successfully
as a rule.
Add a lookahead that checks for the `ident whitespace* ':'` pattern
before attempting declaration parsing. Since declarations must start
with this pattern per spec, we can skip the attempt entirely when it
doesn't match and go straight to qualified rule parsing.
This is a massive win on large Tailwind CSS stylesheets (like the one
used by chatgpt.com) where thousands of rules inside @layer blocks were
being double-parsed. On a 1.2MB Tailwind v4 stylesheet, parse time goes
from ~2000ms to ~95ms (21x speedup).
Filter out unsupported @font-face sources (e.g. .eot files, or sources
with an explicit unsupported format() hint) when populating the
FontFace's URL list, rather than fetching and attempting to decode them.
This matches the behavior of Blink and WebKit, which both reject .eot
URLs by filename when no format() hint is present, to avoid conflicts
with old WinIE-style @font-face rules.
Previously, we would fetch .eot files over the network, fail to decode
them, and then reject the font load promise, leading to a flood of
"NetworkError: Failed to load font" messages in the console.
FontFaceSet::delete_() was calling switch_to_loaded() whenever the
loading fonts list was empty after removing a font, even if the font
was never in the loading list to begin with. Per spec, we should only
switch to loaded if the font was the last item in the loading list.
The #pragma once was placed after the #include directives instead of
immediately after the copyright comment, inconsistent with every other
header file
Per the CSS Transforms spec, when interpolating rotate3d() functions
with equal normalized direction vectors (or when one angle is zero),
the rotation angle should be interpolated numerically rather than
using quaternion slerp.
Previously we always used quaternion slerp, which cannot represent
rotations beyond 360 degrees. This meant that animating from
rotateY(0deg) to rotateY(3600deg) produced no visual animation, since
both quaternions are identical (3600 mod 360 = 0).
Now we detect when axes match and interpolate the angle directly,
correctly preserving multi-turn rotations. This fixes 168 WPT tests.
Per the CSS Animations spec, the animation-timing-function property
describes how the animation progresses between each pair of keyframes,
not as an overall effect-level timing function.
Previously we set it as the effect-level timing function on the
AnimationEffect, which caused easing to be applied to the global
animation progress. This made animations with multiple keyframes
"pause" at the start and end of the full animation cycle instead of
easing smoothly between each pair of keyframes.
Now we:
- Store per-keyframe easing in ResolvedKeyFrame from @keyframes rules
- Store the default easing on CSSAnimation instead of on the effect
- Apply per-keyframe easing to the interval progress during
interpolation, falling back to the CSS animation's default easing
- Also store per-keyframe easing from JS-created KeyframeEffects to
avoid incorrectly applying CSS default easing to replaced effects
When processing CSS animations, we were only looking up @keyframes
rules from the document-level rule cache, passing nullptr for the
shadow root parameter. This meant that @keyframes defined inside
shadow DOM <style> elements were never found, and animations
referencing them would silently have no keyframes.
Fix this by first checking the element's containing shadow root for
@keyframes rules, then falling back to the document-level rules.
