When a shorthand like `background` containing `var()` is used in
a `::selection` rule, the shorthand was filtered out by the pseudo-
element property whitelist before variable resolution could occur.
This left PendingSubstitutionStyleValue longhands unresolved,
causing either a crash or incorrect computed values.
Allow unresolved shorthands to bypass the pseudo-element filter so
variable resolution can proceed. After resolution and expansion
into longhands, filter out any that the pseudo-element does not
support.
Fixes#8625.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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