Also renames the `clear_transitions` function to clarify this doesn't
affect the associated transition animations.
This fixes an issue where transitions weren't being cancelled when the
relevant transition-property entry was no longer present
Before this change, we've been maintaining various StyleComputer caches
at the document level.
This made sense for old-school documents without shadow trees, since
all the style information was document-wide anyway. However, documents
with many shadow trees ended up suffering since any time you mutated
a style sheet inside a shadow tree, *all* style caches for the entire
document would get invalidated.
This was particularly expensive on Reddit, which has tons of shadow
trees with their own style elements. Every time we'd create one of their
custom elements, we'd invalidate the document-level "rule cache" and
have to rebuild it, taking about ~60ms each time (ouch).
This commit introduces a new object called StyleScope.
Every Document and ShadowRoot has its own StyleScope. Rule caches etc
are moved from StyleComputer to StyleScope.
Rule cache invalidation now happens at StyleScope level. As an example,
rule cache rebuilds now take ~1ms on Reddit instead of ~60ms.
This is largely a mechanical change, moving things around, but there's
one key detail to be aware of: due to the :host selector, which works
across the shadow DOM boundary and reaches from inside a shadow tree out
into the light tree, there are various places where we have to check
both the shadow tree's StyleScope *and* the document-level StyleScope
in order to get all rules that may apply.
The exception returned here is never used or logged. Let's just return
a null request, to make it clearer that these are not exceptions shown
to the user (thus not observable).
`play_or_cancel_animations_after_display_property_change` is called
whenever an element is inserted or removed, or it's display property
changes, but it is only required to run if we actually have animations
to play or cancel.
Reduces time spent in the aforementioned function from ~2% to ~0.03%
when loading https://en.wikipedia.org/wiki/2023_in_American_television
We don't need to iterate every property in start_needed_transitions,
only those that appear in transition-property or have an existing
transition
Reduces the time spent in start_needed_transitions from ~5% to ~0.03%
when loading https://en.wikipedia.org/wiki/2023_in_American_television
The majority of time in `compute_font()` was spent in
`font_matching_algorithm()` repeatedly computing the same values. We
now cache these values to avoid unnecessary work.
Makes the `compute_font_variation_settings` function match other
`compute_font_*` by absolutizing values passed into them. It resolves a
crash related to using `siblings-count` inside `font-variation-settings`
Co-authored-by: Sam Atkins <sam@ladybird.org>
Integrates the new `FontVariationSettings` from LibGfx into LibWeb to
enable initial variable font functionality. Currently, only the `wght`
(weight) axis is fully supported and tested. This update also introduces
support for the CSS `font-variation-settings` property.
There were a couple places that we had special handling for the `all`
property but since d31a58a was merged we can treat it the same as any
other shorthand
There are a few places in style computation where we want to update the
value of a property without modifying the inherited or important flags.
Previously we would look up these flags and pass them to the normal
`set_property` method but this is unnecessary and was easy to forget to
do.
We don't need all this specific logic for parsing the `transition`
property - we also now maintain `none` as such until use time which
gains us a couple extra tests
Unrecognized property names should still be kept in the list to preserve
matching of indices (e.g. that the Nth property should associate with
the Nth duration)
Since we now have access to the `AbstractElement` through the
`ComputationContext` we can just set the flag that this element relies
on tree counting functions directly, no need to pass this struct around.
Passing the `AbstractElement` rather than the
`TreeCountingFunctionResolutionContext` allows us to only compute the
resolution context when necessary (i.e. when we actually need to resolve
a tree counting function)
When we compute style for elements inside a UA-internal shadow tree that
represent a pseudo-element (e.g ::placeholder), we actually run the
StyleComputer machinery for (host element :: pseudo-element).
While that lets us match the correct selectors, it was incorrectly
applying CSS inheritance, since we'd also then inherit from whatever was
above the host element in the tree.
This patch fixes the issue by introducing an inheritance override in
AbstractElement and then using that to force inheritance from whatever
is actually directly above in the DOM for these elements instead of
jumping all the way up past the host.
This fixes an issue where `text-align: center` on input type=text
elements would render the main text centered but placeholder text was
still left-aligned.
Tree counting functions should be resolved at style computation time -
to do this we will need to know the element's sibling count and index.
This commit computes that information and propagates it to the various
`StyleValue::to_computed_value` methods.
This excludes `step-end` and `step-start` which are expected to be
converted to the equivalent function at parse time.
We are expected to serialize these as the explicit keywords - previously
we would parse as `EasingStyleValue` and serialize equivalent functions
as the keywords. This caused issues as we would incorrectly serialize
even explicit functions as the keyword.
This also allows us to move the magic easing functions to
`EasingFunction` rather than `EasingStyleValue` which is a bit tidier
This struct will in the future hold information other than a length
resolution context (e.g. context for tree counting functions) and a
single struct is easier to work with than multiple parameters.
This commit modifies the `compute_foo()` code for `font-style` and
`math-depth`. They previously assumed that their StyleValue was always
a special kind: FontStyleStyleValue or MathDepthStyleValue. This was
always true, because that's how we parse them, but it stops being true
once StylePropertyMap is involved: An author can set font-style to a
CSSKeywordValue of "italic", and this should work.
There are multiple ways that we could solve this, but the simplest and
easiest to maintain seems to be to handle those more basic StyleValues
in this computation code. Going forward, we'll have to be aware that
similar properties could have a basic StyleValue from the typed-OM
instead of the property-specific one we'd expect.
Whether an absbox is positioned below or to the right of its previous
sibling in an `InlineFormattingContext` is determined by the
display-outside value before blockification, so we store the
pre-blockification `display` value in `ComputedValues` to access it in
`InlineFormattingContext` and position the box accordingly.
Opacity values are unique in that the range which calculated and
interpolated values should be clamped to [0,1] is different from the
range of allowed values [-∞,∞].
This fixes 28 WPT tests that were regressed in #6112
