These get computed to an equivalent RGBColorStyleValue.
To support this, we now store the computed color-scheme on the
ComputationContext when computing properties that might contain a color.
This has a nice bonus of correcting the css-accent-color test's result.
These generally work as you'd expect. The exceptions are that hsl() and
hwb() are expected to compute to rgb(), so absolutization produces an
RGBColorStyleValue where possible.
Our parsing code was treating `foo` and `foo: bar` as `<media-feature>`s
when really they need to be `(foo)` and `(foo: bar)` respectively. This
previously worked for the valid case because boolean expressions can
also have arbitrary `()` blocks. However, it meant we'd also allow them
without the parentheses which isn't valid.
So instead, parse and serialize the parentheses as part of the
`<media-feature>`. This gets us some WPT passes and fixes an Acid3
failure.
Every user of this actually wants an ancestor in the flat tree - taking
things like `<slot>` into account. So rename it and adjust its behavior
to use that.
Instead of doing a full document style invalidation when a stylesheet is
dynamically added, we now analyze the new sheet's selectors to determine
which elements could potentially be affected, and only invalidate those.
This works by building an InvalidationSet from the rightmost compound
selector (the "subject") of each rule in the new stylesheet, extracting
class, ID, tag name, attribute, and pseudo-class features. We then walk
the DOM tree and only mark elements matching those features as needing a
style update.
If any selector has a rightmost compound that is purely universal (no
identifying features), or uses a pseudo-class not supported by the
invalidation set matching logic, we fall back to full invalidation.
`grid-template-rows: fit-content(100px)` had no effect when the grid
container lacked an explicit height, because the fit-content growth
limit clamping was gated behind `available_size.is_definite()`.
Fix by normalizing fit-content tracks with unresolvable percentage
arguments to max-content during track initialization, then applying
the fit-content clamp unconditionally.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/7730
Previously we would resolve font features
(https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence)
per element, while this works for the current subset of the font feature
resolution algorithm that we support, some as yet unimplemented parts
require us to know whether we are resolving against a CSS @font-face
rule, and if so which one (e.g. applying descriptors from the @font-face
rule, deciding which @font-feature-values rules to apply, etc).
To achieve this we store the data required to resolve font features in a
struct and pass that to `FontComputer` which resolves the font features
and stores them with the computed `Font`.
We no longer need to invalidate the font shaping cache when features
change since the features are defined per font (and therefore won't ever
change).
In a future commit we will require this to be in it's computed form
before calling `ComputedProperties::computed_font_list()`.
We will also depend on other properties (e.g. `font-kerning`,
`font-variant-*`) but these are unaffected by computation.
While our default font supporting variations is unlikely, this is
nevertheless required for our fallback font to be considered equal to
it's non-default/fallback equivalent (i.e. `font-family: serif`) which
in turn is required for LineBuilder to merge chunks into a single
fragment.
The :scope pseudo-class inside :has(), :is(), :where(), and :not()
selectors was not receiving the scoping root from outer selector
contexts like Element.closest().
This fix passes the scope parameter through matches_has_pseudo_class(),
matches_relative_selector(), and the :is()/:where()/:not() cases so
that :scope correctly refers to the scoping root element.
This fixes WPT tests for Element.closest() with selector
':has(> :scope)' and for comparing :has(:scope) with :is(:scope)
selectors.
Previously, any change to a property that affects stacking context would
trigger a full stacking context tree rebuild. However, an element only
creates or destroys a stacking context when a property crosses from its
"neutral" value to a "creating" value (or vice versa).
For example, animating `transform: translateX(10px)` to
`transform: translateX(20px)` previously triggered stacking context
rebuilds on every frame, but this is unnecessary because the stacking
context already exists.
Previously, when a @font-face font finished loading, we would clear the
entire computed font cache and invalidate style for the whole document.
This was overly conservative since most elements don't use the newly
loaded font. We now take a targeted approach inspired by Firefox:
1. Only clear cache entries that reference the loaded font family
2. Walk the DOM tree (including shadow trees) and only invalidate
elements whose font-family property (or pseudo-elements' font-family)
actually references the loaded font
This significantly reduces style invalidation work on pages with many
elements but only some using custom fonts.
Previously, getComputedStyle() would always call update_layout() for
most properties. This was expensive since layout involves a full tree
traversal even when only style information is needed.
This change introduces a more granular approach:
- Properties needing layout computation (used values like width/height)
still call update_layout()
- Properties needing a layout node for resolved value computation
(colors, border widths, etc.) also call update_layout()
- All other properties now only call update_style()
The set of properties needing layout node for resolution is now defined
in Properties.json via the "needs-layout-node-for-resolved-value" flag,
rather than being hardcoded. This is generated into a new function
property_needs_layout_node_for_resolved_value().
Move the visual viewport (pinch-to-zoom) transform from a reserved slot
in DisplayList to the AccumulatedVisualContext tree as a root transform
node. Fixed position elements now correctly inherit from this context.
This requires rebuilding the context tree and display list on each zoom
change, but this overhead will be eliminated by future partial context
tree rebuilds.
I originally wanted to move this to prevent a circular dependency, in a
commit that I'm probably not submitting any more. But also, there's
nothing about this type that is CSS or LibWeb-specific, so let's put
this in AK.
This also required supporting composition for it's constituent types
(`RadialSizeStyleValue` and `BorderRadiusRect`).
The remaining failing subtests in the two affected tests are because we
dont yet support compositing of mixed values
This method was only called when `font_matching_algorithm` failed to
match a font (i.e. there are no fonts with a matching family name) in
which case this method would also fail to match a font.
Previously we wouldn't respect font-variation-settings for fonts matched
through `font_matching_algorithm` (i.e. any fonts which didn't have an
exact loaded match).
