Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/StyleComputer.h

363 lines
16 KiB
C
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
* Copyright (c) 2018-2025, Andreas Kling <andreas@ladybird.org>
LibWeb: Add Document::get_style_sheet_source() This returns the source text of the specified style sheet. StyleComputer now exposes user agent style sheets so that these can also be requested.
2024-08-23 11:03:05 +01:00
* Copyright (c) 2021-2024, Sam Atkins <sam@ladybird.org>
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
*/
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
#pragma once
LibWeb: Handle dependency cycles in CSS var()s :^) We now detect situations like this, where variables infinitely recur, without crashing: ```css div { --a: var(--b); --b: var(--a); background: var(--a); } p { --foo: var(--foo); background: var(--foo); } ```
2021-12-03 20:00:31 +00:00
#include <AK/HashMap.h>
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
#include <AK/Optional.h>
LibHTML: Get rid of the style tree We now create a layout tree directly from the DOM tree. This way we don't actually lose text nodes ^)
2019-09-21 15:32:17 +03:00
#include <AK/OwnPtr.h>
LibGfx+LibWeb: Rename Gfx::VectorFont to Gfx::Typeface Typeface is a more widely used name for the data represented by class previously named VectorFont. Now: - Typeface represents decoded font that is not ready for rendering - ScaledFont represents the combination of typeface and size for rendering
2024-06-28 20:27:00 +02:00
#include <LibGfx/Font/Typeface.h>
LibWeb: Reduced number of recompiled files for CSS property headers This reduces the number of `.cpp` files that need to be recompiled when one of the below header files changes as follows: CSS/ComputedProperties.h: 1113 -> 49 CSS/ComputedValues.h: 1120 -> 209
2025-02-18 09:19:56 +01:00
#include <LibGfx/FontCascadeList.h>
LibWeb: Transition StyleComputer to Web Animations With this commit, we are finally running animations off of the web animations spec! A lot of the work StyleComputer is doing is now done elsewhere. For example, fill-forward animations are handled by Animation::is_relevant() returning true in the after phase, meaning the "active_state_if_fill_forward" map is no longer needed.
2024-02-22 13:56:15 +00:00
#include <LibWeb/Animations/KeyframeEffect.h>
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
#include <LibWeb/CSS/CSSFontFaceRule.h>
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 23:30:54 +03:30
#include <LibWeb/CSS/CSSKeyframesRule.h>
LibWeb: Resolve custom properties The way to get the custom properties is pretty weird and this code is as far from optimized as it gets but somehow it works :^)
2021-05-24 23:02:58 +02:00
#include <LibWeb/CSS/CSSStyleDeclaration.h>
LibWeb: Split StyleComputer work into two phases with separate outputs Before this change, StyleComputer would essentially take a DOM element, find all the CSS rules that apply to it, and resolve the computed value for each CSS property for that element. This worked great, but it meant we had to do all the work of selector matching and cascading every time. To enable new optimizations, this change introduces a break in the middle of this process where we've produced a "CascadedProperties". This object contains the result of the cascade, before we've begun turning cascaded values into computed values. The cascaded properties are now stored with each element, which will later allow us to do partial updates without re-running the full StyleComputer machine. This will be particularly valuable for re-implementing CSS inheritance, which is extremely heavy today. Note that CSS animations and CSS transitions operate entirely on the computed values, even though the cascade order would have you believe they happen earlier. I'm not confident we have the right architecture for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
#include <LibWeb/CSS/CascadeOrigin.h>
#include <LibWeb/CSS/CascadedProperties.h>
LibWeb: Match styles for pseudo-elements Since each selector can only have zero or one pseudo-element, we match against it as a separate step, before matching the rest of the selector. This should be faster, but mostly I did this because I could not figure out how else to stop selectors without a pseudo-element from matching the pseudo-element, eg so `.foo` styles don't affect `.foo::before`.
2022-02-24 15:54:12 +00:00
#include <LibWeb/CSS/Selector.h>
LibWeb: Use invalidation sets to reduce style recalculation Implements idea described in https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8 Invalidation sets are used to reduce the number of elements marked for style recalculation by collecting metadata from style rules about the dependencies between properties that could affect an element’s style. Currently, this optimization is only applied to style invalidation triggered by class list mutations on an element.
2025-01-12 18:38:05 +03:00
#include <LibWeb/CSS/StyleInvalidationData.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
#include <LibWeb/Export.h>
LibWeb: Move DOM classes into the Web::DOM namespace LibWeb keeps growing and the Web namespace is filling up fast. Let's put DOM stuff into Web::DOM, just like we already started doing with SVG stuff in Web::SVG.
2020-07-26 19:37:56 +02:00
#include <LibWeb/Forward.h>
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
#include <LibWeb/Loader/ResourceLoader.h>
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
namespace Web::CSS {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Use an ancestor filter to quickly reject many CSS selectors Given a selector like `.foo .bar #baz`, we know that elements with the class names `foo` and `bar` must be present in the ancestor chain of the candidate element, or the selector cannot match. By keeping track of the current ancestor chain during style computation, and which strings are used in tag names and attribute names, we can do a quick check before evaluating the selector itself, to see if all the required ancestors are present. The way this works: 1. CSS::Selector now has a cache of up to 8 strings that must be present in the ancestor chain of a matching element. Note that we actually store string *hashes*, not the strings themselves. 2. When Document performs a recursive style update, we now push and pop elements to the ancestor chain stack as they are entered and exited. 3. When entering/exiting an ancestor, StyleComputer collects all the relevant string hashes from that ancestor element and updates a counting bloom filter. 4. Before evaluating a selector, we first check if any of the hashes required by the selector are definitely missing from the ancestor filter. If so, it cannot be a match, and we reject it immediately. 5. Otherwise, we carry on and evaluate the selector as usual. I originally tried doing this with a HashMap, but we ended up losing a huge chunk of the time saved to HashMap instead. As it turns out, a simple counting bloom filter is way better at handling this. The cost is a flat 8KB per StyleComputer, and since it's a bloom filter, false positives are a thing. This is extremely efficient, and allows us to quickly reject the majority of selectors on many huge websites. Some example rejection rates: - https://amazon.com: 77% - https://github.com/SerenityOS/serenity: 61% - https://nytimes.com: 57% - https://store.steampowered.com: 55% - https://en.wikipedia.org: 45% - https://youtube.com: 32% - https://shopify.com: 25% This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
// A counting bloom filter with 2 hash functions.
// NOTE: If a counter overflows, it's kept maxed-out until the whole filter is cleared.
template<typename CounterType, size_t key_bits>
class CountingBloomFilter {
public:
CountingBloomFilter() { }
void clear() { __builtin_memset(m_buckets, 0, sizeof(m_buckets)); }
void increment(u32 key)
{
auto& first = bucket1(key);
if (first < NumericLimits<CounterType>::max())
++first;
auto& second = bucket2(key);
if (second < NumericLimits<CounterType>::max())
++second;
}
void decrement(u32 key)
{
auto& first = bucket1(key);
if (first < NumericLimits<CounterType>::max())
--first;
auto& second = bucket2(key);
if (second < NumericLimits<CounterType>::max())
--second;
}
[[nodiscard]] bool may_contain(u32 hash) const
{
return bucket1(hash) && bucket2(hash);
}
private:
static constexpr u32 bucket_count = 1 << key_bits;
static constexpr u32 key_mask = bucket_count - 1;
[[nodiscard]] u32 hash1(u32 key) const { return key & key_mask; }
[[nodiscard]] u32 hash2(u32 key) const { return (key >> 16) & key_mask; }
[[nodiscard]] CounterType& bucket1(u32 key) { return m_buckets[hash1(key)]; }
[[nodiscard]] CounterType& bucket2(u32 key) { return m_buckets[hash2(key)]; }
[[nodiscard]] CounterType bucket1(u32 key) const { return m_buckets[hash1(key)]; }
[[nodiscard]] CounterType bucket2(u32 key) const { return m_buckets[hash2(key)]; }
CounterType m_buckets[bucket_count];
};
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
struct MatchingRule {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<DOM::ShadowRoot const> shadow_root;
GC::Ptr<CSSRule const> rule; // Either CSSStyleRule or CSSNestedDeclarations
GC::Ptr<CSSStyleSheet const> sheet;
LibWeb: Cache style sheet's default namespace in MatchingRule This avoids looking up the default namespace rule for every rule we consider running. Shaves ~900ms of loading time off of https://wpt.fyi/
2025-01-26 13:58:28 +01:00
Optional<FlyString> default_namespace;
LibWeb: Add direct pointer to CSS::Selector in MatchingRule struct This avoids looking up the selector by index repeatedly, giving us a ~400ms reduction in load time on https://wpt.fyi/
2025-01-25 19:57:11 +01:00
Selector const& selector;
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
size_t style_sheet_index { 0 };
size_t rule_index { 0 };
LibWeb: Add CSS rule buckets for pseudo elements, and for :root If a selector must match a pseudo element, or must match the root element, we now cache that information in the MatchingRule struct. We also introduce separate buckets for these rules, so we can avoid running them altogether if the current element can't possibly match. This cuts the number of selectors evaluated by 32% when loading our GitHub repo page https://github.com/SerenityOS/serenity
2024-03-13 11:47:25 +01:00
LibWeb: StyleResolver: Keep track of specificity of matched selector This way it gets easier to compare matches.
2021-05-24 23:01:24 +02:00
u32 specificity { 0 };
LibWeb: Reorder MatchingRule members to make it smaller By packing the members more efficiently, it goes from 64 to 56 bytes.
2024-03-18 16:01:47 +01:00
CascadeOrigin cascade_origin;
LibWeb: Make CSS rule cache smarter about pseudo elements Instead of putting every rule that matches a pseudo element in the same bucket, let them go in the best ID/class/tag name bucket instead. Then, add a flag to MatchingRule that says whether it contains a pseudo element in the rightmost compound selector. When deciding which selectors to run for an element, we can now simply filter in/out pseudo element selectors as appropriate depending on what we're trying to match. This fixes an issue where pages using Font Awesome had 1700+ rules in the pseudo-element rule cache. (This meant all those rules had to run against every element twice or more while instantiating pseudo elements.)
2023-03-09 19:27:23 +01:00
bool contains_pseudo_element { false };
LibWeb: Add `::slotted()` pseudo-element support Implements `::slotted()` to enough extent we could pass the imported WPT test and make substantial layout correctness improvement on https://www.rottentomatoes.com/
2025-09-03 14:58:35 +02:00
bool slotted { false };
LibWeb/CSS: Process style properties from CSSNestedDeclarations rules These are created when a style rule has properties listed after another rule. For example: ```css .test { --a: 1; --b: 1; --c: 1; .thing { /* ... */ } /* These are after a rule (.thing) so they're wrapped in a CSSNestedDeclarations: */ --d: 1; --e: 1; --f: 1; } ``` They're treated like a nested style rule with the exact same selectors as their containing style rule.
2024-10-17 13:48:00 +01:00
// Helpers to deal with the fact that `rule` might be a CSSStyleRule or a CSSNestedDeclarations
LibWeb/CSS: Merge style declaration subclasses into CSSStyleProperties We previously had PropertyOwningCSSStyleDeclaration and ResolvedCSSStyleDeclaration, representing the current style properties and resolved style respectively. Both of these were the CSSStyleDeclaration type in the CSSOM. (We also had ElementInlineCSSStyleDeclaration but I removed that in a previous commit.) In the meantime, the spec has changed so that these should now be a new CSSStyleProperties type in the CSSOM. Also, we need to subclass CSSStyleDeclaration for things like CSSFontFaceRule's list of descriptors, which means it wouldn't hold style properties. So, this commit does the fairly messy work of combining these two types into a new CSSStyleProperties class. A lot of what previously was done as separate methods in the two classes, now follows the spec steps of "if the readonly flag is set, do X" instead, which is hopefully easier to follow too. There is still some functionality in CSSStyleDeclaration that belongs in CSSStyleProperties, but I'll do that next. To avoid a huge diff for "CSSStyleDeclaration-all-supported-properties-and-default-values.txt" both here and in the following commit, we don't apply the (currently empty) CSSStyleProperties prototype yet.
2025-03-17 17:50:49 +00:00
CSSStyleProperties const& declaration() const;
LibWeb/CSS: Process style properties from CSSNestedDeclarations rules These are created when a style rule has properties listed after another rule. For example: ```css .test { --a: 1; --b: 1; --c: 1; .thing { /* ... */ } /* These are after a rule (.thing) so they're wrapped in a CSSNestedDeclarations: */ --d: 1; --e: 1; --f: 1; } ``` They're treated like a nested style rule with the exact same selectors as their containing style rule.
2024-10-17 13:48:00 +01:00
SelectorList const& absolutized_selectors() const;
FlyString const& qualified_layer_name() const;
LibWeb: Sort matched style rules by specificity, document order If two rules have equal specificity, they should be applied in the order in which we encountered them.
2020-06-13 00:44:26 +02:00
};
LibWeb: Compare font keys by reference `StyleComputer::font_matching_algorithm` was creating a copy of a `FlyString` every time a `MatchingFontCandidate` was constructed or copied, causing millions of unnecessairy reference updates when a lot of fonts are loaded. While a more permanent solution would be to not load so many unused fonts, let's do the right thing and remove the unnecessairy copies of `FlyString`.
2024-10-26 23:35:58 +02:00
struct FontFaceKey;
struct OwnFontFaceKey {
explicit OwnFontFaceKey(FontFaceKey const& other);
operator FontFaceKey() const;
[[nodiscard]] u32 hash() const { return pair_int_hash(family_name.hash(), pair_int_hash(weight, slope)); }
[[nodiscard]] bool operator==(OwnFontFaceKey const& other) const = default;
[[nodiscard]] bool operator==(FontFaceKey const& other) const;
LibWeb: Honor font-weight and font-style when using downloaded fonts Instead of keying downloaded @font-face fonts on just the family name, we now key them on a tuple of the family name, weight and slope.
2023-05-24 15:35:30 +02:00
FlyString family_name;
int weight { 0 };
int slope { 0 };
};
LibWeb: Prepare RuleCache for being reusable to store hover rules Moves code that allows to add and iterate over rules in cache into methods defined for RuleCache.
2025-02-20 21:07:22 +01:00
struct RuleCache {
HashMap<FlyString, Vector<MatchingRule>> rules_by_id;
HashMap<FlyString, Vector<MatchingRule>> rules_by_class;
HashMap<FlyString, Vector<MatchingRule>> rules_by_tag_name;
HashMap<FlyString, Vector<MatchingRule>, AK::ASCIICaseInsensitiveFlyStringTraits> rules_by_attribute_name;
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
Array<Vector<MatchingRule>, to_underlying(CSS::PseudoElement::KnownPseudoElementCount)> rules_by_pseudo_element;
LibWeb: Prepare RuleCache for being reusable to store hover rules Moves code that allows to add and iterate over rules in cache into methods defined for RuleCache.
2025-02-20 21:07:22 +01:00
Vector<MatchingRule> root_rules;
LibWeb: Add `::slotted()` pseudo-element support Implements `::slotted()` to enough extent we could pass the imported WPT test and make substantial layout correctness improvement on https://www.rottentomatoes.com/
2025-09-03 14:58:35 +02:00
Vector<MatchingRule> slotted_rules;
LibWeb: Prepare RuleCache for being reusable to store hover rules Moves code that allows to add and iterate over rules in cache into methods defined for RuleCache.
2025-02-20 21:07:22 +01:00
Vector<MatchingRule> other_rules;
HashMap<FlyString, NonnullRefPtr<Animations::KeyframeEffect::KeyFrameSet>> rules_by_animation_keyframes;
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
void add_rule(MatchingRule const&, Optional<PseudoElement>, bool contains_root_pseudo_class);
LibWeb/CSS: Take AbstractElement in for_each_matching_rules()
2025-09-09 14:48:51 +01:00
void for_each_matching_rules(DOM::AbstractElement, Function<IterationDecision(Vector<MatchingRule> const&)> callback) const;
LibWeb: Prepare RuleCache for being reusable to store hover rules Moves code that allows to add and iterate over rules in cache into methods defined for RuleCache.
2025-02-20 21:07:22 +01:00
};
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
class FontLoader;
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API StyleComputer final : public GC::Cell {
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
GC_CELL(StyleComputer, GC::Cell);
GC_DECLARE_ALLOCATOR(StyleComputer);
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
public:
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
static void for_each_property_expanding_shorthands(PropertyID, StyleValue const&, Function<void(PropertyID, StyleValue const&)> const& set_longhand_property);
LibWeb: Rename `get_inherit_value` to `get_non_animated_inherit_value` This more acurately represents what it does.
2025-08-28 23:42:46 +12:00
static NonnullRefPtr<StyleValue const> get_non_animated_inherit_value(PropertyID, DOM::AbstractElement);
LibWeb/CSS: Take AbstractElement in StyleComputer::get_*_inherit_value()
2025-09-09 12:25:40 +01:00
static Optional<NonnullRefPtr<StyleValue const>> get_animated_inherit_value(PropertyID, DOM::AbstractElement);
LibWeb: Expose CSS shorthand -> longhand conversion This conversion needs to be done by KeyframEffect as well
2024-02-24 08:36:24 -07:00
LibWeb: Add Document::get_style_sheet_source() This returns the source text of the specified style sheet. StyleComputer now exposes user agent style sheets so that these can also be requested.
2024-08-23 11:03:05 +01:00
static Optional<String> user_agent_style_sheet_source(StringView name);
LibWeb: Rename CSS::StyleResolver => StyleComputer Resolved style is a spec concept that refers to the weird mix of computed style and used style reflected by getComputedStyle(). The purpose of this class is to produce the *computed* style for a given element, so let's call it StyleComputer.
2021-09-24 13:49:57 +02:00
explicit StyleComputer(DOM::Document&);
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
~StyleComputer();
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
LibWeb: Move DOM classes into the Web::DOM namespace LibWeb keeps growing and the Web namespace is filling up fast. Let's put DOM stuff into Web::DOM, just like we already started doing with SVG stuff in Web::SVG.
2020-07-26 19:37:56 +02:00
DOM::Document& document() { return m_document; }
LibWeb: Convert StyleResolver.{h,cpp} to east const
2021-07-14 16:56:11 +01:00
DOM::Document const& document() const { return m_document; }
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
LibWeb: Use an ancestor filter to quickly reject many CSS selectors Given a selector like `.foo .bar #baz`, we know that elements with the class names `foo` and `bar` must be present in the ancestor chain of the candidate element, or the selector cannot match. By keeping track of the current ancestor chain during style computation, and which strings are used in tag names and attribute names, we can do a quick check before evaluating the selector itself, to see if all the required ancestors are present. The way this works: 1. CSS::Selector now has a cache of up to 8 strings that must be present in the ancestor chain of a matching element. Note that we actually store string *hashes*, not the strings themselves. 2. When Document performs a recursive style update, we now push and pop elements to the ancestor chain stack as they are entered and exited. 3. When entering/exiting an ancestor, StyleComputer collects all the relevant string hashes from that ancestor element and updates a counting bloom filter. 4. Before evaluating a selector, we first check if any of the hashes required by the selector are definitely missing from the ancestor filter. If so, it cannot be a match, and we reject it immediately. 5. Otherwise, we carry on and evaluate the selector as usual. I originally tried doing this with a HashMap, but we ended up losing a huge chunk of the time saved to HashMap instead. As it turns out, a simple counting bloom filter is way better at handling this. The cost is a flat 8KB per StyleComputer, and since it's a bloom filter, false positives are a thing. This is extremely efficient, and allows us to quickly reject the majority of selectors on many huge websites. Some example rejection rates: - https://amazon.com: 77% - https://github.com/SerenityOS/serenity: 61% - https://nytimes.com: 57% - https://store.steampowered.com: 55% - https://en.wikipedia.org: 45% - https://youtube.com: 32% - https://shopify.com: 25% This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
void reset_ancestor_filter();
void push_ancestor(DOM::Element const&);
void pop_ancestor(DOM::Element const&);
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 16:35:12 +01:00
[[nodiscard]] GC::Ref<ComputedProperties> create_document_style() const;
LibWeb: Don't compute full style for ::before/::after unless matched Before this patch, we would build full computed style for these pseudo elements, for every DOM element, even if no ::before/::after selector actually matched. This was a colossal waste of time, and we can also just not do that. Instead, just abort pseudo element style resolution early if no relevant selectors matched. :^)
2023-03-14 16:36:20 +01:00
LibWeb: Take AbstractElement in StyleComputer::compute_style()
2025-09-05 14:56:12 +01:00
[[nodiscard]] GC::Ref<ComputedProperties> compute_style(DOM::AbstractElement, Optional<bool&> did_change_custom_properties = {}) const;
LibWeb/CSS: Take AbstractElement in compute_pe_style_if_needed()
2025-09-09 11:40:06 +01:00
[[nodiscard]] GC::Ptr<ComputedProperties> compute_pseudo_element_style_if_needed(DOM::AbstractElement, Optional<bool&> did_change_custom_properties) const;
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
LibWeb: Make :hover invalidation logic reusable for all pseudo classes We achieve this by keeping track of all checked pseudo class selectors in the SelectorEngine code. We also give StyleComputer per-pseudo-class rule caches.
2025-04-17 13:39:30 +02:00
[[nodiscard]] RuleCache const& get_pseudo_class_rule_cache(PseudoClass) const;
LibWeb/CSS: Take AbstractElement in MatchingRule collection
2025-09-09 14:01:23 +01:00
[[nodiscard]] Vector<MatchingRule const*> collect_matching_rules(DOM::AbstractElement, CascadeOrigin, PseudoClassBitmap& attempted_pseudo_class_matches, Optional<FlyString const> qualified_layer_name = {}) const;
LibHTML: Implement some very simple selector matching. We walk the entire DOM and check all selectors against all elements. Only id, class and tag name are checked right now. There's no ancestor stack or compound selectors. All in good time :^)
2019-06-27 20:40:21 +02:00
LibWeb: Use invalidation sets to reduce style recalculation Implements idea described in https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8 Invalidation sets are used to reduce the number of elements marked for style recalculation by collecting metadata from style rules about the dependencies between properties that could affect an element’s style. Currently, this optimization is only applied to style invalidation triggered by class list mutations on an element.
2025-01-12 18:38:05 +03:00
InvalidationSet invalidation_set_for_properties(Vector<InvalidationSet::Property> const&) const;
bool invalidation_property_used_in_has_selector(InvalidationSet::Property const&) const;
LibWeb: Don't rebuild rule cache so eagerly to check for :has/:defined Instead, change the APIs from "has :foo" to "may have :foo" and return true if we don't have a valid rule cache at the moment. This allows us to defer the rebuilding of the rule cache until a later time, for the cost of a wider invalidation at the moment. Do note that if our rule cache is invalid, the whole document has invalid style anyway! So this is actually always less work. :^) Knocks ~1 second of loading time off of https://wpt.fyi/
2025-01-24 10:29:51 +01:00
[[nodiscard]] bool has_valid_rule_cache() const { return m_author_rule_cache; }
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
void invalidate_rule_cache();
LibWeb: Stub getting the initial font instead of the root one Previously this queried the root layout-node's font, which was both wrong and could crash if the layout wasn't ready yet. Now, it's just wrong. But at least all the font-related wrongness is grouped together in StyleComputer. :^)
2022-03-11 12:53:32 +00:00
Gfx::Font const& initial_font() const;
LibWeb: Port FontCache to new Strings
2023-02-17 14:06:55 +00:00
void did_load_font(FlyString const& family_name);
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
GC::Ptr<FontLoader> load_font_face(ParsedFontFace const&, ESCAPING Function<void(RefPtr<Gfx::Typeface const>)> on_load = {});
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
LibWeb: Remove all font loaders linked to a StyleSheet when it's deleted When a style sheet is removed, all font loaders created from that style sheet should also be removed.
2024-09-22 18:10:46 +02:00
void load_fonts_from_sheet(CSSStyleSheet&);
void unload_fonts_from_sheet(CSSStyleSheet&);
LibWeb: Load fonts from style sheet once when sheet is added Previously, we were running the "load fonts if needed" machine at the start of every style computation. That was a lot of unnecessary work, especially on sites with lots of style rules, since we had to traverse every style sheet to see if any @font-face rules needed loading. With this patch, we now load fonts once per sheet, right after adding it to a document's style sheet list.
2022-04-08 21:27:35 +02:00
LibWeb: Implement "preserves overrides" property of editing commands
2024-12-22 21:34:50 +01:00
static CSSPixels default_user_font_size();
LibWeb: Separate relative sizes from `absolute_size_mapping` Having relative sizes handled in this function was misleading
2025-08-29 17:52:45 +12:00
static CSSPixels absolute_size_mapping(AbsoluteSize, CSSPixels default_font_size);
static CSSPixels relative_size_mapping(RelativeSize, CSSPixels inherited_font_size);
LibWeb: Store font-style in ComputedProperties in computed form
2025-09-03 18:57:32 +12:00
RefPtr<Gfx::FontCascadeList const> compute_font_for_style_values(StyleValue const& font_family, CSSPixels const& font_size, int font_slope, double font_weight, Percentage const& font_width) const;
LibWeb/CSS: Take AbstractElement in font computation methods
2025-09-09 11:55:45 +01:00
[[nodiscard]] RefPtr<StyleValue const> recascade_font_size_if_needed(DOM::AbstractElement, CascadedProperties&) const;
LibWeb: Implement time-traveling inheritance for CSS font-size When setting `font-family: monospace;` in CSS, we have to interpret the keyword font sizes (small, medium, large, etc) as slightly smaller for historical reasons. Normally the medium font size is 16px, but for monospace it's 13px. The way this needs to behave is extremely strange: When encountering `font-family: monospace`, we have to go back and replay the CSS cascade as if the medium font size had been 13px all along. Otherwise relative values like 2em/200%/etc could have gotten lost in the inheritance chain. We implement this in a fairly naive way by explicitly checking for `font-family: monospace` (note: it has to be *exactly* like that, it can't be `font-family: monospace, Courier` or similar.) When encountered, we simply walk the element ancestors and re-run the cascade for the font-size property. This is clumsy and inefficient, but it does work for the common cases. Other browsers do more elaborate things that we should eventually care about as well, such as user-configurable font settings, per-language behavior, etc. For now, this is just something that allows us to handle more WPT tests where things fall apart due to unexpected font sizes. To learn more about the wonders of font-size, see this blog post: https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/
2025-02-25 11:47:03 +01:00
LibWeb: Cache the viewport rect across all of style computation Fetching the viewport rect is currently somewhat expensive, since it requires finding the navigable the document is active in. We can avoid the cost of repeated calls by simply allowing StyleComputer to cache the viewport rect at the start of style computation.
2024-01-11 14:04:18 +01:00
void set_viewport_rect(Badge<DOM::Document>, CSSPixelRect const& viewport_rect) { m_viewport_rect = viewport_rect; }
LibWeb/CSS: Take AbstractElement in collect_animation_into()
2025-09-09 13:49:34 +01:00
void collect_animation_into(DOM::AbstractElement, GC::Ref<Animations::KeyframeEffect> animation, ComputedProperties&) const;
LibWeb: Add fast path for animated style properties update Patch up existing style properties instead of using the regular style invalidation path, which requires rule matching for each element in the invalidated subtree. - !important properties: this change introduces a flag used to skip the update of animated properties overridden by !important. - inherited animated properties: for now, these are invalidated by traversing animated element's subtree to propagate the update. - StyleProperties has a separate array for animated properties that allows the removal animated properties after animation has ended, without requiring full style invalidation.
2024-03-16 07:44:48 +01:00
LibWeb: Don't rebuild rule cache so eagerly to check for :has/:defined Instead, change the APIs from "has :foo" to "may have :foo" and return true if we don't have a valid rule cache at the moment. This allows us to defer the rebuilding of the rule cache until a later time, for the cost of a wider invalidation at the moment. Do note that if our rule cache is invalid, the whole document has invalid style anyway! So this is actually always less work. :^) Knocks ~1 second of loading time off of https://wpt.fyi/
2025-01-24 10:29:51 +01:00
[[nodiscard]] bool may_have_has_selectors() const;
LibWeb: Skip pending `:has()` invalidations if there are no `:has()` `invalidate_style()` already tries to avoid scheduling invalidation for `:has()` by checking result of `may_have_has_selectors()`, but it might still result in unnecessary work because `may_have_has_selectors()` does not force building of rules cache. This change adds `have_has_selectors()` that forces building of rules cache and is invoked in `update_style()` to double-check whether we actually need to process scheduled `:has()` invalidations. This allows to skip ~100000 ancestor traversals on this WPT test: https://wpt.live/html/select/options-length-too-large.html
2025-02-10 19:03:09 +01:00
[[nodiscard]] bool have_has_selectors() const;
LibWeb: Cache whether there are any :has() selectors present As useful as they may be to web developers, :has() selectors complicate the style invalidation process quite a lot. Let's have StyleComputer keep track of whether they are present at all in the current set of active style sheets. This will allow us to implement fast-path optimizations when there are no :has() selectors.
2024-09-19 13:27:37 +02:00
LibWeb: Resolve document.fonts.ready() after fonts defined in CSS loaded This is an ad-hoc implementation that resolves the ready() promise once the document and all fonts collected by the style computer are done loading. A spec-compliant implementation would include creating a proxy CSS::FontFace for each @font-face and correctly implementing the specification steps for font fetching, but we are far from there yet. This hackish implementation should yield good WPT progress because it will actually start waiting for the Ahem font to load before capturing layout measurements. For example, it makes https://wpt.live/css/css-grid/abspos/positioned-grid-descendants-001.html go from 0/100 to 36/100 passing subtests.
2024-09-29 23:38:49 +02:00
size_t number_of_css_font_faces_with_loading_in_progress() const;
LibWeb/CSS: Take AbstractElement in StyleComputer::compute_properties() As noted, the chunk of this method that deals with animations could do with some helpers on AbstractElement, but I'm leaving that until it's clearer how animations and pseudo-elements should interact.
2025-09-09 12:44:00 +01:00
[[nodiscard]] GC::Ref<ComputedProperties> compute_properties(DOM::AbstractElement, CascadedProperties&) const;
LibWeb: Split StyleComputer work into two phases with separate outputs Before this change, StyleComputer would essentially take a DOM element, find all the CSS rules that apply to it, and resolve the computed value for each CSS property for that element. This worked great, but it meant we had to do all the work of selector matching and cascading every time. To enable new optimizations, this change introduces a break in the middle of this process where we've produced a "CascadedProperties". This object contains the result of the cascade, before we've begun turning cascaded values into computed values. The cascaded properties are now stored with each element, which will later allow us to do partial updates without re-running the full StyleComputer machine. This will be particularly valuable for re-implementing CSS inheritance, which is extremely heavy today. Note that CSS animations and CSS transitions operate entirely on the computed values, even though the cascade order would have you believe they happen earlier. I'm not confident we have the right architecture for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
LibWeb: Initial work to store ComputedProperties in computed form `StyleValue`s stored within `ComputedProperties` should be in their computed forms, this is for various reasons including: - Inheritance should be of computed values - Animations should work on computed values - Triggering transitions should work on computed values Currently we store `StyleValue`s in an absolutized version of the specified value - this is equivalent to the computed form in many cases which is why this hasn't been causing significant issues but there are some cases - such as `border-*-width` keywords where this is not the case. No functionality change as we are yet to implement any properties
2025-08-26 14:48:47 +12:00
void compute_property_values(ComputedProperties&) const;
LibWeb/CSS: Take AbstractElement in font computation methods
2025-09-09 11:55:45 +01:00
void compute_font(ComputedProperties&, Optional<DOM::AbstractElement>) const;
LibWeb: Add mechanism to invalidate only inherited styles We can now mark an element as needing an "inherited style update" rather than a full "style update". This effectively means that the next style update will visit the element and pull all of its inherited properties from the relevant ancestor element. This is now used for descendants of elements with animated style.
2024-12-22 11:59:58 +01:00
LibWeb: Mark `should_reject_with_ancestor_filter()` as inline
2025-02-19 20:14:00 +01:00
[[nodiscard]] inline bool should_reject_with_ancestor_filter(Selector const&) const;
LibWeb: Use ancestor filters for hover style invalidation By using ancestor filters some selectors could be early rejected skipping selector engine invocation. According to my measurements it's 30-80% hover selectors depending on the website.
2025-01-28 03:04:04 +01:00
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
static NonnullRefPtr<StyleValue const> compute_value_of_custom_property(DOM::AbstractElement, FlyString const& custom_property, Optional<Parser::GuardedSubstitutionContexts&> = {});
LibWeb: Produce computed values for custom properties Custom properties are required to produce a computed value just like regular properties. The computed value is defined in the spec as "specified value with variables substituted, or the guaranteed-invalid value", though in reality all arbitrary substitution functions should be substituted, not just `var()`. To support this, we parse the CSS-wide keywords normally in custom properties, instead of ignoring them. We don't yet handle all of them properly, and because that will require us to cascade them like regular properties. This is just enough to prevent regressions when implementing ASFs. Our output in this new test is not quite correct, because of the awkward way we handle whitespace in property values - so it has 3 spaces in the middle instead of 1, until that's fixed. It's possible this computed-value production should go in cascade_custom_properties(), but I had issues with that. Hopefully once we start cascading custom properties properly, it'll be clearer how this should all work.
2025-06-26 16:48:33 +01:00
LibWeb: Initial work to store ComputedProperties in computed form `StyleValue`s stored within `ComputedProperties` should be in their computed forms, this is for various reasons including: - Inheritance should be of computed values - Animations should work on computed values - Triggering transitions should work on computed values Currently we store `StyleValue`s in an absolutized version of the specified value - this is equivalent to the computed form in many cases which is why this hasn't been causing significant issues but there are some cases - such as `border-*-width` keywords where this is not the case. No functionality change as we are yet to implement any properties
2025-08-26 14:48:47 +12:00
struct PropertyValueComputationContext {
Length::ResolutionContext length_resolution_context;
LibWeb: Store `border-*-width` in computed form in ComputedProperties Gains us 112 new passes since we now interpolate keywords (thick, thin, etc) correctly. Also loses us 4 WPT tests as we longer clamp negative values produced by interpolation from the point of view of getComputedStyle (although the 'used' value is still clamped).
2025-08-28 02:07:57 +12:00
double device_pixels_per_css_pixel;
LibWeb: Initial work to store ComputedProperties in computed form `StyleValue`s stored within `ComputedProperties` should be in their computed forms, this is for various reasons including: - Inheritance should be of computed values - Animations should work on computed values - Triggering transitions should work on computed values Currently we store `StyleValue`s in an absolutized version of the specified value - this is equivalent to the computed form in many cases which is why this hasn't been causing significant issues but there are some cases - such as `border-*-width` keywords where this is not the case. No functionality change as we are yet to implement any properties
2025-08-26 14:48:47 +12:00
};
static NonnullRefPtr<StyleValue const> compute_value_of_property(PropertyID, NonnullRefPtr<StyleValue const> const& specified_value, Function<NonnullRefPtr<StyleValue const>(PropertyID)> const& get_property_specified_value, PropertyValueComputationContext const&);
LibWeb: Store `animation-name` in ComputedProperties in computed form
2025-09-16 17:34:50 +12:00
static NonnullRefPtr<StyleValue const> compute_animation_name(NonnullRefPtr<StyleValue const> const& specified_value, PropertyValueComputationContext const&);
LibWeb: Store `border-*-width` in computed form in ComputedProperties Gains us 112 new passes since we now interpolate keywords (thick, thin, etc) correctly. Also loses us 4 WPT tests as we longer clamp negative values produced by interpolation from the point of view of getComputedStyle (although the 'used' value is still clamped).
2025-08-28 02:07:57 +12:00
static NonnullRefPtr<StyleValue const> compute_border_or_outline_width(NonnullRefPtr<StyleValue const> const& specified_value, NonnullRefPtr<StyleValue const> const& style_specified_value, PropertyValueComputationContext const&);
LibWeb: Decouple font-size computation from compute_font_for_syle_values There are other places we want to convert font-size into it's computed form than just when we are loading the font (e.g. computing keyframes). Gains us 36 WPT passes as we now correctly clamp negative calc values.
2025-08-29 19:32:46 +12:00
static NonnullRefPtr<StyleValue const> compute_font_size(NonnullRefPtr<StyleValue const> const& specified_value, int computed_math_depth, CSSPixels inherited_font_size, int inherited_math_depth, Length::ResolutionContext const& parent_length_resolution_context);
LibWeb: Store font-style in ComputedProperties in computed form
2025-09-03 18:57:32 +12:00
static NonnullRefPtr<StyleValue const> compute_font_style(NonnullRefPtr<StyleValue const> const& specified_value, Length::ResolutionContext const& parent_length_resolution_context);
LibWeb: Store font-weight in ComputedProperties in computed form We now also more closely follow the spec when computing values for font-weight and we now: - Support relative lengths in `calc()`s - Properly clamp `calc()`s - Support relative keywords (e.g. lighter, bolder) - Respect that font-weight can be a non-integer number. This does expose a few false positives in the font-weight-computed.html WPT test. This is because we don't recompute non-inherited font-weight within `recompute_inherited_style` which means that relative keyword values can fall out of sync with their parent's value. These previously passed as we treated `bolder` and `lighter` as aliases for `bold` and `normal` respectively.
2025-09-02 01:14:06 +12:00
static NonnullRefPtr<StyleValue const> compute_font_weight(NonnullRefPtr<StyleValue const> const& specified_value, double inherited_font_weight, Length::ResolutionContext const& parent_length_resolution_context);
LibWeb: Store font-width in ComputedProperties in computed form
2025-09-02 20:43:10 +12:00
static NonnullRefPtr<StyleValue const> compute_font_width(NonnullRefPtr<StyleValue const> const& specified_value, Length::ResolutionContext const& parent_length_resolution_context);
LibWeb: Don't deduplicate `font-variation-settings` values at parse time We now only deduplicate and sort the computed value of the `font-variation-settings` property.
2025-09-19 16:44:18 +01:00
static NonnullRefPtr<StyleValue const> compute_font_variation_settings(NonnullRefPtr<StyleValue const> const& specified_value);
LibWeb: Store `line-height` in ComputedProperties in computed form We now fail a few more tests in properties-value-inherit-001.txt as we no longer overwrite the non-animated value of `line-height` with the animated value, this is in line with other major browsers.
2025-09-23 20:53:07 +12:00
static NonnullRefPtr<StyleValue const> compute_line_height(NonnullRefPtr<StyleValue const> const& specified_value, Length::ResolutionContext const&);
LibWeb: Store `opacity` in computed form in ComputedProperties
2025-09-08 00:05:45 +12:00
static NonnullRefPtr<StyleValue const> compute_opacity(NonnullRefPtr<StyleValue const> const& specified_value, PropertyValueComputationContext const&);
LibWeb: Correctly resolve `position-area` computed value
2025-09-29 10:55:12 +01:00
static NonnullRefPtr<StyleValue const> compute_position_area(NonnullRefPtr<StyleValue const> const& specified_value);
LibWeb: Parse and compute `text-underline-offset` property
2025-09-11 22:00:19 +12:00
static NonnullRefPtr<StyleValue const> compute_text_underline_offset(NonnullRefPtr<StyleValue const> const& specified_value, PropertyValueComputationContext const&);
LibWeb: Initial work to store ComputedProperties in computed form `StyleValue`s stored within `ComputedProperties` should be in their computed forms, this is for various reasons including: - Inheritance should be of computed values - Animations should work on computed values - Triggering transitions should work on computed values Currently we store `StyleValue`s in an absolutized version of the specified value - this is equivalent to the computed form in many cases which is why this hasn't been causing significant issues but there are some cases - such as `border-*-width` keywords where this is not the case. No functionality change as we are yet to implement any properties
2025-08-26 14:48:47 +12:00
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
private:
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
virtual void visit_edges(Visitor&) override;
LibWeb: Don't compute full style for ::before/::after unless matched Before this patch, we would build full computed style for these pseudo elements, for every DOM element, even if no ::before/::after selector actually matched. This was a colossal waste of time, and we can also just not do that. Instead, just abort pseudo element style resolution early if no relevant selectors matched. :^)
2023-03-14 16:36:20 +01:00
enum class ComputeStyleMode {
Normal,
CreatePseudoElementStyleIfNeeded,
};
LibWeb: Consider system fonts when looking for inexact weight match Previously, we only considered loaded (web) fonts.
2023-08-17 18:45:06 +02:00
struct MatchingFontCandidate;
LibWeb: Make font selection closer to specification Add matching on family name, style and weight. This improves the fonts used by the MDN examples.
2023-05-29 02:16:16 +00:00
LibWeb: Avoid duplicate work when computing style Before this change we were running the CSS cascade machinery twice per element: - First, to compute the "logical alias mapping context" based on writing-mode and pals. - Then, to compute all properties. This patch factors out the heaviest work from the cascade machinery to a separate step that can be run only once. This step will: - Collect all the matching rules for the element - Resolve custom properties for the element We still perform the per-element cascade twice, but now this is hogging less than 1% of CPU time when typing on Discord (compared to 9% before.)
2025-07-20 15:00:32 +02:00
struct LayerMatchingRules {
FlyString qualified_layer_name;
Vector<MatchingRule const*> rules;
};
struct MatchingRuleSet {
Vector<MatchingRule const*> user_agent_rules;
Vector<MatchingRule const*> user_rules;
Vector<LayerMatchingRules> author_rules;
};
LibWeb/CSS: Take AbstractElement in MatchingRule collection
2025-09-09 14:01:23 +01:00
[[nodiscard]] MatchingRuleSet build_matching_rule_set(DOM::AbstractElement, PseudoClassBitmap& attempted_pseudo_class_matches, bool& did_match_any_pseudo_element_rules, ComputeStyleMode) const;
LibWeb: Avoid duplicate work when computing style Before this change we were running the CSS cascade machinery twice per element: - First, to compute the "logical alias mapping context" based on writing-mode and pals. - Then, to compute all properties. This patch factors out the heaviest work from the cascade machinery to a separate step that can be run only once. This step will: - Collect all the matching rules for the element - Resolve custom properties for the element We still perform the per-element cascade twice, but now this is hogging less than 1% of CPU time when typing on Discord (compared to 9% before.)
2025-07-20 15:00:32 +02:00
LibWeb/CSS: Take AbstractElement to compute alias mapping contexts
2025-09-09 14:40:48 +01:00
LogicalAliasMappingContext compute_logical_alias_mapping_context(DOM::AbstractElement, ComputeStyleMode, MatchingRuleSet const&) const;
LibWeb: Take AbstractElement in compute_style_impl()
2025-09-09 12:10:08 +01:00
[[nodiscard]] GC::Ptr<ComputedProperties> compute_style_impl(DOM::AbstractElement, ComputeStyleMode, Optional<bool&> did_change_custom_properties) const;
LibWeb/CSS: Take AbstractElement in compute_cascaded_values()
2025-09-09 14:21:12 +01:00
[[nodiscard]] GC::Ref<CascadedProperties> compute_cascaded_values(DOM::AbstractElement, bool did_match_any_pseudo_element_rules, ComputeStyleMode, MatchingRuleSet const&, Optional<LogicalAliasMappingContext>, ReadonlySpan<PropertyID> properties_to_cascade) const;
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
static RefPtr<Gfx::FontCascadeList const> find_matching_font_weight_ascending(Vector<MatchingFontCandidate> const& candidates, int target_weight, float font_size_in_pt, bool inclusive);
static RefPtr<Gfx::FontCascadeList const> find_matching_font_weight_descending(Vector<MatchingFontCandidate> const& candidates, int target_weight, float font_size_in_pt, bool inclusive);
LibWeb: Compare font keys by reference `StyleComputer::font_matching_algorithm` was creating a copy of a `FlyString` every time a `MatchingFontCandidate` was constructed or copied, causing millions of unnecessairy reference updates when a lot of fonts are loaded. While a more permanent solution would be to not load so many unused fonts, let's do the right thing and remove the unnecessairy copies of `FlyString`.
2024-10-26 23:35:58 +02:00
RefPtr<Gfx::FontCascadeList const> font_matching_algorithm(FlyString const& family_name, int weight, int slope, float font_size_in_pt) const;
LibWeb: Produce computed values for custom properties Custom properties are required to produce a computed value just like regular properties. The computed value is defined in the spec as "specified value with variables substituted, or the guaranteed-invalid value", though in reality all arbitrary substitution functions should be substituted, not just `var()`. To support this, we parse the CSS-wide keywords normally in custom properties, instead of ignoring them. We don't yet handle all of them properly, and because that will require us to cascade them like regular properties. This is just enough to prevent regressions when implementing ASFs. Our output in this new test is not quite correct, because of the awkward way we handle whitespace in property values - so it has 3 spaces in the middle instead of 1, until that's fixed. It's possible this computed-value production should go in cascade_custom_properties(), but I had issues with that. Hopefully once we start cascading custom properties properly, it'll be clearer how this should all work.
2025-06-26 16:48:33 +01:00
void compute_custom_properties(ComputedProperties&, DOM::AbstractElement) const;
LibWeb: Support relative lengths in `math-depth` calcs As this is computed before font-size we use the parent's length resolution context.
2025-08-21 17:12:56 +12:00
void compute_math_depth(ComputedProperties&, Optional<DOM::AbstractElement>) const;
LibWeb/CSS: Take AbstractElement in start_needed_transitions()
2025-09-09 14:13:57 +01:00
void start_needed_transitions(ComputedProperties const& old_style, ComputedProperties& new_style, DOM::AbstractElement) const;
LibWeb: Rename CSS::StyleProperties => CSS::ComputedProperties Now that StyleProperties is only used to hold computed properties, let's name it ComputedProperties.
2024-12-20 11:32:17 +01:00
void resolve_effective_overflow_values(ComputedProperties&) const;
LibWeb/CSS: Take AbstractElement in box-type transformation functions
2025-09-09 14:34:26 +01:00
void transform_box_type_if_needed(ComputedProperties&, DOM::AbstractElement) const;
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
template<typename Callback>
LibWeb: Start implementing the CSS cascade The 'C' in "CSS" is for Cascade, so let's actually implement the cascade in LibWeb. :^) StyleResolver::resolve_style() now begins by collecting all the matching CSS rules for the given DOM::Element. Rules are then processed in the spec's cascade order (instead of in the order we encounter them.) With this, "!important" is now honored on CSS properties. After performing the cascade, we do another pass of what the spec calls "defaulting" where we resolve "inherit" and "initial" values. I've left a FIXME about supporting correct "initial" values for every property, since we're currently lacking some coverage there. Note that this mechanism now resolves every known CSS property. This is *not* space-efficient and we'll eventually need to come up with some strategies to reduce memory usage around this. However, this will do fine until we have more of the engine working correctly. :^)
2021-09-21 11:38:18 +02:00
void for_each_stylesheet(CascadeOrigin, Callback) const;
LibWeb: Cache the viewport rect across all of style computation Fetching the viewport rect is currently somewhat expensive, since it requires finding the navigable the document is active in. We can avoid the cost of repeated calls by simply allowing StyleComputer to cache the viewport rect at the start of style computation.
2024-01-11 14:04:18 +01:00
[[nodiscard]] CSSPixelRect viewport_rect() const { return m_viewport_rect; }
LibWeb: Rename CSS::StyleProperties => CSS::ComputedProperties Now that StyleProperties is only used to hold computed properties, let's name it ComputedProperties.
2024-12-20 11:32:17 +01:00
[[nodiscard]] Length::FontMetrics calculate_root_element_font_metrics(ComputedProperties const&) const;
LibWeb: Give StyleComputer a helper for getting the current viewport
2022-03-19 18:08:52 +01:00
LibWeb/CSS: Implement cascade layers (aka `@layer`) This is done quite simply for now, there are certainly optimizations that can and should be made later. With this we now pass: - http://wpt.live/css/css-cascade/layer-basic.html - http://wpt.live/css/css-cascade/layer-important.html - http://wpt.live/css/css-cascade/layer-statement-copy-crash.html - http://wpt.live/css/css-cascade/layer-stylesheet-sharing-important.html - http://wpt.live/css/css-cascade/layer-stylesheet-sharing.html - http://wpt.live/css/css-cascade/layer-vs-inline-style.html
2024-09-04 17:43:18 +01:00
Vector<FlyString> m_qualified_layer_names_in_order;
void build_qualified_layer_names_cache();
LibWeb: Split StyleComputer work into two phases with separate outputs Before this change, StyleComputer would essentially take a DOM element, find all the CSS rules that apply to it, and resolve the computed value for each CSS property for that element. This worked great, but it meant we had to do all the work of selector matching and cascading every time. To enable new optimizations, this change introduces a break in the middle of this process where we've produced a "CascadedProperties". This object contains the result of the cascade, before we've begun turning cascaded values into computed values. The cascaded properties are now stored with each element, which will later allow us to do partial updates without re-running the full StyleComputer machine. This will be particularly valuable for re-implementing CSS inheritance, which is extremely heavy today. Note that CSS animations and CSS transitions operate entirely on the computed values, even though the cascade order would have you believe they happen earlier. I'm not confident we have the right architecture for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
void cascade_declarations(
CascadedProperties&,
LibWeb/CSS: Take AbstractElement in cascade_declarations()
2025-09-09 11:34:09 +01:00
DOM::AbstractElement,
LibWeb: Avoid copying large MatchingRule objects inside StyleComputer Instead of creating and passing around Vector<MatchingRule> inside StyleComputer (internally, not exposed in API), we now use vectors of pointers/references instead. Note that we use pointers in case we want to quick_sort() the vectors. Knocks 4 seconds of loading time off of https://wpt.fyi/
2025-01-24 15:47:42 +01:00
Vector<MatchingRule const*> const&,
LibWeb: Split StyleComputer work into two phases with separate outputs Before this change, StyleComputer would essentially take a DOM element, find all the CSS rules that apply to it, and resolve the computed value for each CSS property for that element. This worked great, but it meant we had to do all the work of selector matching and cascading every time. To enable new optimizations, this change introduces a break in the middle of this process where we've produced a "CascadedProperties". This object contains the result of the cascade, before we've begun turning cascaded values into computed values. The cascaded properties are now stored with each element, which will later allow us to do partial updates without re-running the full StyleComputer machine. This will be particularly valuable for re-implementing CSS inheritance, which is extremely heavy today. Note that CSS animations and CSS transitions operate entirely on the computed values, even though the cascade order would have you believe they happen earlier. I'm not confident we have the right architecture for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
CascadeOrigin,
Important,
LibWeb: Map logical aliases at cascade time Previously we would incorrectly map these in `CSSStyleProperties::convert_declarations_to_specified_order`, aside from being too early (as it meant we didn't maintain them as distinct from their physical counterparts in CSSStyleProperties), this meant that we didn't yet have the required context to map them correctly. We now map them as part of the cascade process. To compute the mapping context we do a cascade without mapping, and extract the relevant properties (writing-direction and direction).
2025-06-18 17:45:26 +12:00
Optional<FlyString> layer_name,
LibWeb: Only cascade relevant CSS properties for logical alias context We only need the cascaded values for writing-mode and direction when resolving the logical alias context, so we can skip all other properties.
2025-07-21 14:29:12 +02:00
Optional<LogicalAliasMappingContext>,
ReadonlySpan<PropertyID> properties_to_cascade) const;
LibHTML: Make StyleResolver responsible for loading the default style Instead of HtmlView clients having to worry about parsing and loading the default CSS, just take care of it inside StyleResolver. The default style is automatically inserted into the stylesheet list, at the very start, so everyone else gets a chance to override it.
2019-10-05 09:01:12 +02:00
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
void build_rule_cache();
void build_rule_cache_if_needed() const;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<DOM::Document> m_document;
LibWeb: Cache CSS rules in buckets to reduce number of rules checked This patch introduces the StyleComputer::RuleCache, which divides all of our (author) CSS rules into buckets. Currently, there are two buckets: - Rules where a specific class must be present. - All other rules. This allows us to check a significantly smaller set of rules for each element, since we can skip over any rule that requires a class attribute not present on the element. This takes the typical numer of rules tested per element on Discord from ~16000 to ~550. :^) We can definitely improve the cache invalidation. It currently happens too often due to media queries. And we also need to make sure we invalidate when mutating style through CSSOM APIs.
2022-02-10 17:49:50 +01:00
LibWeb: Collect interesting document-wide insights about CSS selectors Starting out with these two things: - Whether any :has() selectors are present - The set of all names referenced by attribute selectors
2024-12-23 15:22:10 +01:00
struct SelectorInsights {
bool has_has_selectors { false };
};
LibWeb: Segregate StyleComputer rule caches per Document-or-ShadowRoot This means we only need to consider rules from the document and the current shadow root, instead of the document and *every* shadow root. Dramatically reduces the amount of rules processed on many pages. Shaves 2.5 seconds of load time off of https://wpt.fyi/ :^)
2025-01-27 18:28:48 +01:00
struct RuleCaches {
RuleCache main;
HashMap<FlyString, NonnullOwnPtr<RuleCache>> by_layer;
LibWeb: Add per-layer rule caches in StyleComputer This allows us to filter by layer *once* instead of doing it for every rule that runs. Knocks ~2 seconds of loading time off of https://wpt.fyi/
2025-01-24 10:27:52 +01:00
};
LibWeb: Implement the CSS rule cache optimization for UA style as well We were already sorting the author style selectors into buckets. Now we do it for the built-in UA style as well. This means less work for the selector engine everywhere :^)
2023-03-07 20:13:13 +01:00
LibWeb: Segregate StyleComputer rule caches per Document-or-ShadowRoot This means we only need to consider rules from the document and the current shadow root, instead of the document and *every* shadow root. Dramatically reduces the amount of rules processed on many pages. Shaves 2.5 seconds of load time off of https://wpt.fyi/ :^)
2025-01-27 18:28:48 +01:00
struct RuleCachesForDocumentAndShadowRoots {
RuleCaches for_document;
HashMap<GC::Ref<DOM::ShadowRoot const>, NonnullOwnPtr<RuleCaches>> for_shadow_roots;
};
LibWeb: Bucket hover rules using RuleCache Analysis of selectors on modern websites shows that the `:hover` pseudo-class is mostly used in the subject position within relatively simple selectors like `.a:hover`. This suggests that we could greatly benefit from segregating them by id/class/tag name, this way reducing number of selectors tested during hover style invalidation. With this change, hover invalidation on Discord goes down from 70ms to 3ms on my machine. I also tested GMail and GitHub where this change shows nice 2x-3x speedup.
2025-02-20 21:53:31 +01:00
void make_rule_cache_for_cascade_origin(CascadeOrigin, SelectorInsights&);
LibWeb: Segregate StyleComputer rule caches per Document-or-ShadowRoot This means we only need to consider rules from the document and the current shadow root, instead of the document and *every* shadow root. Dramatically reduces the amount of rules processed on many pages. Shaves 2.5 seconds of load time off of https://wpt.fyi/ :^)
2025-01-27 18:28:48 +01:00
LibWeb: Don't put unlayered rules into into empty "service" layer Fixes bug when `build_matching_rule_set()` mistakenly included all unlayered rules twice. This was caused by mistakenly including all unlayered rules into `""` named "service" layer, because we couldn't tell if FlyString = `""` means no layer or layer named `""`.
2025-07-21 12:59:00 +02:00
[[nodiscard]] RuleCache const* rule_cache_for_cascade_origin(CascadeOrigin, Optional<FlyString const> qualified_layer_name, GC::Ptr<DOM::ShadowRoot const>) const;
LibWeb: Implement the CSS rule cache optimization for UA style as well We were already sorting the author style selectors into buckets. Now we do it for the built-in UA style as well. This means less work for the selector engine everywhere :^)
2023-03-07 20:13:13 +01:00
LibWeb: Collect interesting document-wide insights about CSS selectors Starting out with these two things: - Whether any :has() selectors are present - The set of all names referenced by attribute selectors
2024-12-23 15:22:10 +01:00
static void collect_selector_insights(Selector const&, SelectorInsights&);
OwnPtr<SelectorInsights> m_selector_insights;
LibWeb: Make :hover invalidation logic reusable for all pseudo classes We achieve this by keeping track of all checked pseudo class selectors in the SelectorEngine code. We also give StyleComputer per-pseudo-class rule caches.
2025-04-17 13:39:30 +02:00
Array<OwnPtr<RuleCache>, to_underlying(PseudoClass::__Count)> m_pseudo_class_rule_cache;
LibWeb: Use invalidation sets to reduce style recalculation Implements idea described in https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8 Invalidation sets are used to reduce the number of elements marked for style recalculation by collecting metadata from style rules about the dependencies between properties that could affect an element’s style. Currently, this optimization is only applied to style invalidation triggered by class list mutations on an element.
2025-01-12 18:38:05 +03:00
OwnPtr<StyleInvalidationData> m_style_invalidation_data;
LibWeb: Segregate StyleComputer rule caches per Document-or-ShadowRoot This means we only need to consider rules from the document and the current shadow root, instead of the document and *every* shadow root. Dramatically reduces the amount of rules processed on many pages. Shaves 2.5 seconds of load time off of https://wpt.fyi/ :^)
2025-01-27 18:28:48 +01:00
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_author_rule_cache;
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_user_rule_cache;
OwnPtr<RuleCachesForDocumentAndShadowRoots> m_user_agent_rule_cache;
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
GC::Ptr<CSSStyleSheet> m_user_style_sheet;
LibWeb: Load and use fonts described by @font-face rules :^) When encountering a @font-face rule, StyleComputer will now fire off a resource request and download the first source URL specified. Once downloaded, we try to parse it as a TrueType font file, and if it works, it's added to a cache in StyleComputer. This effectively makes fonts per-document since every document has its own StyleComputer. This is very unoptimized and could definitely use some caching, etc. But it does work on Acid3. :^)
2022-03-29 02:14:20 +02:00
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
using FontLoaderList = Vector<GC::Ref<FontLoader>>;
LibWeb: Compare font keys by reference `StyleComputer::font_matching_algorithm` was creating a copy of a `FlyString` every time a `MatchingFontCandidate` was constructed or copied, causing millions of unnecessairy reference updates when a lot of fonts are loaded. While a more permanent solution would be to not load so many unused fonts, let's do the right thing and remove the unnecessairy copies of `FlyString`.
2024-10-26 23:35:58 +02:00
HashMap<OwnFontFaceKey, FontLoaderList> m_loaded_fonts;
LibWeb: Cache the root element font metrics when calculating them The root element font metrics were getting queried again and again during style computation. Before this change we would do some work to recalculate them each time. This patch simply caches them in a StyleComputer member. Since style updates always start with the root element, we know that it'll be up-to-date by the time we look at any other element. Before this change, we were spending ~5% of CPU time on Google Groups in root_element_font_metrics().
2023-05-08 10:28:21 +02:00
Length::FontMetrics m_default_font_metrics;
Length::FontMetrics m_root_element_font_metrics;
LibWeb: Add preliminary support for CSS animations This partially implements CSS-Animations-1 (though there are references to CSS-Animations-2). Current limitations: - Multi-selector keyframes are not supported. - Most animation properties are ignored. - Timing functions are not applied. - Non-absolute values are not interpolated unless the target is also of the same non-absolute type (e.g. 10% -> 25%, but not 10% -> 20px). - The JavaScript interface is left as an exercise for the next poor soul looking at this code. With those said, this commit implements: - Interpolation for most common types - Proper keyframe resolution (including the synthetic from-keyframe containing the initial state) - Properly driven animations, and proper style invalidation Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-05-26 23:30:54 +03:30
LibWeb: Cache the viewport rect across all of style computation Fetching the viewport rect is currently somewhat expensive, since it requires finding the navigable the document is active in. We can avoid the cost of repeated calls by simply allowing StyleComputer to cache the viewport rect at the start of style computation.
2024-01-11 14:04:18 +01:00
CSSPixelRect m_viewport_rect;
LibWeb: Use an ancestor filter to quickly reject many CSS selectors Given a selector like `.foo .bar #baz`, we know that elements with the class names `foo` and `bar` must be present in the ancestor chain of the candidate element, or the selector cannot match. By keeping track of the current ancestor chain during style computation, and which strings are used in tag names and attribute names, we can do a quick check before evaluating the selector itself, to see if all the required ancestors are present. The way this works: 1. CSS::Selector now has a cache of up to 8 strings that must be present in the ancestor chain of a matching element. Note that we actually store string *hashes*, not the strings themselves. 2. When Document performs a recursive style update, we now push and pop elements to the ancestor chain stack as they are entered and exited. 3. When entering/exiting an ancestor, StyleComputer collects all the relevant string hashes from that ancestor element and updates a counting bloom filter. 4. Before evaluating a selector, we first check if any of the hashes required by the selector are definitely missing from the ancestor filter. If so, it cannot be a match, and we reject it immediately. 5. Otherwise, we carry on and evaluate the selector as usual. I originally tried doing this with a HashMap, but we ended up losing a huge chunk of the time saved to HashMap instead. As it turns out, a simple counting bloom filter is way better at handling this. The cost is a flat 8KB per StyleComputer, and since it's a bloom filter, false positives are a thing. This is extremely efficient, and allows us to quickly reject the majority of selectors on many huge websites. Some example rejection rates: - https://amazon.com: 77% - https://github.com/SerenityOS/serenity: 61% - https://nytimes.com: 57% - https://store.steampowered.com: 55% - https://en.wikipedia.org: 45% - https://youtube.com: 32% - https://shopify.com: 25% This also yields a chunky 37% speedup on StyleBench. :^)
2024-03-22 13:50:33 +01:00
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
OwnPtr<CountingBloomFilter<u8, 14>> m_ancestor_filter;
LibHTML: Start fleshing out a StyleResolver class. This will be responsible for matching selectors and creating LayoutStyle objects for the document and its elements.
2019-06-27 17:47:59 +02:00
};
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
class FontLoader final : public GC::Cell {
GC_CELL(FontLoader, GC::Cell);
GC_DECLARE_ALLOCATOR(FontLoader);
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
public:
LibWeb/CSS: Use CSS::URL for font-fetching ParsedFontFace and FontLoader now both keep track of which CSSStyleSheet (if any) was the source of the font-face, so the URLs can be completed correctly.
2025-05-02 12:07:22 +01:00
FontLoader(StyleComputer& style_computer, GC::Ptr<CSSStyleSheet> parent_style_sheet, FlyString family_name, Vector<Gfx::UnicodeRange> unicode_ranges, Vector<URL> urls, ESCAPING Function<void(RefPtr<Gfx::Typeface const>)> on_load = {});
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
LibWeb/CSS: Load fonts using fetch Convert FontLoader to use fetch_a_style_resource(). ResourceLoader used to keep its downloaded data around for us, but fetch doesn't, so we use Gfx::Typeface::try_load_from_temporary_memory() so that the font has a permanent copy of that data.
2025-05-01 16:16:57 +01:00
virtual ~FontLoader();
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
Vector<Gfx::UnicodeRange> const& unicode_ranges() const { return m_unicode_ranges; }
LibGfx+LibWeb: Store Typeface and Font-related types in RefPtr to const
2025-04-15 15:48:14 -06:00
RefPtr<Gfx::Typeface const> vector_font() const { return m_vector_font; }
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
LibGfx+LibWeb: Store Typeface and Font-related types in RefPtr to const
2025-04-15 15:48:14 -06:00
RefPtr<Gfx::Font const> font_with_point_size(float point_size);
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
void start_loading_next_url();
LibWeb/CSS: Load fonts using fetch Convert FontLoader to use fetch_a_style_resource(). ResourceLoader used to keep its downloaded data around for us, but fetch doesn't, so we use Gfx::Typeface::try_load_from_temporary_memory() so that the font has a permanent copy of that data.
2025-05-01 16:16:57 +01:00
bool is_loading() const;
LibWeb: Resolve document.fonts.ready() after fonts defined in CSS loaded This is an ad-hoc implementation that resolves the ready() promise once the document and all fonts collected by the style computer are done loading. A spec-compliant implementation would include creating a proxy CSS::FontFace for each @font-face and correctly implementing the specification steps for font fetching, but we are far from there yet. This hackish implementation should yield good WPT progress because it will actually start waiting for the Ahem font to load before capturing layout measurements. For example, it makes https://wpt.live/css/css-grid/abspos/positioned-grid-descendants-001.html go from 0/100 to 36/100 passing subtests.
2024-09-29 23:38:49 +02:00
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
private:
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
virtual void visit_edges(Visitor&) override;
LibWeb/CSS: Load fonts using fetch Convert FontLoader to use fetch_a_style_resource(). ResourceLoader used to keep its downloaded data around for us, but fetch doesn't, so we use Gfx::Typeface::try_load_from_temporary_memory() so that the font has a permanent copy of that data.
2025-05-01 16:16:57 +01:00
ErrorOr<NonnullRefPtr<Gfx::Typeface const>> try_load_font(Fetch::Infrastructure::Response const&, ByteBuffer const&);
LibWeb: Make CSS font loader tolerate WPT web server shenanigans The web server for WPT has a tendency to just disconnect after sending us a resource. This makes curl think an error occurred, but it's actually still recoverable and we have the data. So instead of just bailing, do what we already do for other kinds of resources and try to parse the data we got. If it works out, great! It would be nice to solve this in the networking layer instead, but I'll leave that as an exercise for our future selves.
2024-09-21 18:35:31 +02:00
LibWeb/CSS: Load fonts using fetch Convert FontLoader to use fetch_a_style_resource(). ResourceLoader used to keep its downloaded data around for us, but fetch doesn't, so we use Gfx::Typeface::try_load_from_temporary_memory() so that the font has a permanent copy of that data.
2025-05-01 16:16:57 +01:00
void font_did_load_or_fail(RefPtr<Gfx::Typeface const>);
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
GC::Ref<StyleComputer> m_style_computer;
LibWeb/CSS: Use CSS::URL for font-fetching ParsedFontFace and FontLoader now both keep track of which CSSStyleSheet (if any) was the source of the font-face, so the URLs can be completed correctly.
2025-05-02 12:07:22 +01:00
GC::Ptr<CSSStyleSheet> m_parent_style_sheet;
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
FlyString m_family_name;
Vector<Gfx::UnicodeRange> m_unicode_ranges;
LibGfx+LibWeb: Store Typeface and Font-related types in RefPtr to const
2025-04-15 15:48:14 -06:00
RefPtr<Gfx::Typeface const> m_vector_font;
LibWeb/CSS: Use CSS::URL for font-fetching ParsedFontFace and FontLoader now both keep track of which CSSStyleSheet (if any) was the source of the font-face, so the URLs can be completed correctly.
2025-05-02 12:07:22 +01:00
Vector<URL> m_urls;
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
GC::Ptr<Fetch::Infrastructure::FetchController> m_fetch_controller;
LibWeb/CSS: Load fonts using fetch Convert FontLoader to use fetch_a_style_resource(). ResourceLoader used to keep its downloaded data around for us, but fetch doesn't, so we use Gfx::Typeface::try_load_from_temporary_memory() so that the font has a permanent copy of that data.
2025-05-01 16:16:57 +01:00
Function<void(RefPtr<Gfx::Typeface const>)> m_on_load;
LibWeb: Expose StyleComputer's FontLoader class publicly We'll want to explicitly load fonts from FontFace and other Web APIs in the future. A future refactor should also move this completely away from StyleComputer and call it something like 'FontCache'.
2024-05-15 14:58:24 -06:00
};
LibWeb: Mark `should_reject_with_ancestor_filter()` as inline
2025-02-19 20:14:00 +01:00
inline bool StyleComputer::should_reject_with_ancestor_filter(Selector const& selector) const
{
for (u32 hash : selector.ancestor_hashes()) {
if (hash == 0)
break;
LibWeb: Make StyleComputer and FontLoader GC-allocated This allows them to keep style sheets alive while loading fonts for them. Fixes some GC crashes seen on the WPT WOFF2 tests after 66a19b85501dad8c0bfc5577b8d0b835877ad0dc stopped FetchRecord leaks from keeping various other things alive.
2025-07-30 14:38:41 +02:00
if (!m_ancestor_filter->may_contain(hash))
LibWeb: Mark `should_reject_with_ancestor_filter()` as inline
2025-02-19 20:14:00 +01:00
return true;
}
return false;
}
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink