dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/CSS/CascadedProperties.cpp

149 lines
5.4 KiB
C++
Raw Permalink Normal View History

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 06:06:29 -03:00
/*
* Copyright (c) 2024, Andreas Kling <andreas@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
#include <LibGC/WeakInlines.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 06:06:29 -03:00
#include <LibWeb/CSS/CSSStyleDeclaration.h>
#include <LibWeb/CSS/CascadedProperties.h>
LibWeb: Include PropertyID.h in fewer header files This reduces the size of the recompile when PropertyID.h is modified from ~1500 to ~125
2025-10-24 10:11:58 -03:00
#include <LibWeb/CSS/PropertyID.h>
LibWeb: Add some missing includes These were being transitively included before via ParsingContext.h, but that will break in a subsequent commit.
2025-02-05 08:54:17 -03:00
#include <LibWeb/DOM/Element.h>
LibWeb: Fix @keyframes resolution for slotted elements A @keyframes rule scoped to a shadow root was not reliably reached from an animated slotted light-DOM element: the keyframes lookup walked the element's own root first, then fell back to the document, but slotted elements can pick up animation-name from a ::slotted(...) rule that lives in an ancestor shadow root rather than in the element's own tree. Track the shadow-root scope that supplied each winning cascaded declaration, and use that scope to resolve the matching @keyframes when processing animation definitions. A shared constructable stylesheet can be adopted into several scopes at once, so the declaration object alone is too weak as a key; the per-entry shadow-root pointer disambiguates which adoption actually contributed. Also refresh running CSS animations' keyframe sets when style is recomputed. Previously only the first animation creation path set a keyframe set, so an existing animation never picked up newly inserted @keyframes rules.
2026-04-22 03:52:18 -03:00
#include <LibWeb/DOM/ShadowRoot.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 06:06:29 -03:00
namespace Web::CSS {
Meta: Enforce newlines around namespaces This has come up several times during code review, so let's just enforce it using a new clang-format 20 option.
2025-05-13 08:06:33 -03:00
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 06:06:29 -03:00
CascadedProperties::CascadedProperties() = default;
CascadedProperties::~CascadedProperties() = default;
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
NonnullRefPtr<CascadedProperties> CascadedProperties::create()
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 06:06:29 -03:00
{
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
return adopt_ref(*new CascadedProperties);
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 06:06:29 -03:00
}
void CascadedProperties::revert_property(PropertyID property_id, Important important, CascadeOrigin cascade_origin)
{
auto it = m_properties.find(property_id);
if (it == m_properties.end())
return;
auto& entries = it->value;
entries.remove_all_matching([&](auto& entry) {
LibWeb: Route presentational hints through the CSS cascade Previously, presentational hints bypassed the regular cascade pipeline and wrote directly into `CascadedProperties` under `CascadeOrigin::Author`. That meant `var()` substitution and the invalid-at-computed-value-time fallback had to be duplicated in a separate per-element pass, which in practice missed the IACVT step and could leave a `GuaranteedInvalidStyleValue` in the cascaded properties. This caused a crash in downstream code that assumed the value had been resolved. This introduces an `AuthorPresentationalHint` cascade origin and feeds them through the cascade as normal declarations. This means that `var()` resolution now happens in only one place.
2026-04-30 06:44:26 -03:00
// https://drafts.csswg.org/css-cascade-5/#author-presentational-hint-origin
// For the purpose of cascading this author presentational hint origin is treated as an independent origin, but
// for the purpose of the revert keyword it is considered part of the author origin.
auto origin_matches = entry.origin == cascade_origin
|| (cascade_origin == CascadeOrigin::Author && entry.origin == CascadeOrigin::AuthorPresentationalHint);
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 06:06:29 -03:00
return entry.property.property_id == property_id
&& entry.property.important == important
LibWeb: Route presentational hints through the CSS cascade Previously, presentational hints bypassed the regular cascade pipeline and wrote directly into `CascadedProperties` under `CascadeOrigin::Author`. That meant `var()` substitution and the invalid-at-computed-value-time fallback had to be duplicated in a separate per-element pass, which in practice missed the IACVT step and could leave a `GuaranteedInvalidStyleValue` in the cascaded properties. This caused a crash in downstream code that assumed the value had been resolved. This introduces an `AuthorPresentationalHint` cascade origin and feeds them through the cascade as normal declarations. This means that `var()` resolution now happens in only one place.
2026-04-30 06:44:26 -03:00
&& origin_matches;
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 06:06:29 -03:00
});
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
if (entries.is_empty()) {
m_contained_properties_cache.set(to_underlying(property_id), false);
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 06:06:29 -03:00
m_properties.remove(it);
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
}
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 06:06:29 -03:00
}
LibWeb: Account for shadow contexts in the cascade Apply author declarations in encapsulation-context order before layer, specificity, scope proximity, and source-order tie breaking. Normal author rules now cascade from inner shadow contexts outward. This lets outer contexts override component defaults. Important author rules cascade the other way so inner contexts can enforce requirements. Keep the ordering context-bucketed. The common document-only path still collects and sorts one author context. Custom properties follow the same context order. var() substitution now observes the same winners as longhand properties. Make revert-layer remove declarations only from the matching cascade origin, context, and layer. This keeps presentational hints and values from other shadow contexts available when one context rolls back its own layer. Add coverage for document and shadow-host competition, slotted rules, nested slot contexts, inline styles, important declarations, custom properties, and revert-layer across shadow contexts.
2026-05-31 06:18:12 -03:00
void CascadedProperties::revert_layer_property(PropertyID property_id, Important important, CascadeOrigin cascade_origin, Optional<FlyString> layer_name, GC::Ptr<DOM::ShadowRoot const> source_shadow_root)
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 06:06:29 -03:00
{
auto it = m_properties.find(property_id);
if (it == m_properties.end())
return;
auto& entries = it->value;
entries.remove_all_matching([&](auto& entry) {
return entry.property.property_id == property_id
&& entry.property.important == important
LibWeb: Account for shadow contexts in the cascade Apply author declarations in encapsulation-context order before layer, specificity, scope proximity, and source-order tie breaking. Normal author rules now cascade from inner shadow contexts outward. This lets outer contexts override component defaults. Important author rules cascade the other way so inner contexts can enforce requirements. Keep the ordering context-bucketed. The common document-only path still collects and sorts one author context. Custom properties follow the same context order. var() substitution now observes the same winners as longhand properties. Make revert-layer remove declarations only from the matching cascade origin, context, and layer. This keeps presentational hints and values from other shadow contexts available when one context rolls back its own layer. Add coverage for document and shadow-host competition, slotted rules, nested slot contexts, inline styles, important declarations, custom properties, and revert-layer across shadow contexts.
2026-05-31 06:18:12 -03:00
&& entry.origin == cascade_origin
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
&& entry.source_shadow_root.ptr() == source_shadow_root
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 06:06:29 -03:00
&& layer_name == entry.layer_name;
});
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
if (entries.is_empty()) {
m_contained_properties_cache.set(to_underlying(property_id), false);
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 06:06:29 -03:00
m_properties.remove(it);
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
}
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 06:06:29 -03:00
}
LibWeb: Fix @keyframes resolution for slotted elements A @keyframes rule scoped to a shadow root was not reliably reached from an animated slotted light-DOM element: the keyframes lookup walked the element's own root first, then fell back to the document, but slotted elements can pick up animation-name from a ::slotted(...) rule that lives in an ancestor shadow root rather than in the element's own tree. Track the shadow-root scope that supplied each winning cascaded declaration, and use that scope to resolve the matching @keyframes when processing animation definitions. A shared constructable stylesheet can be adopted into several scopes at once, so the declaration object alone is too weak as a key; the per-entry shadow-root pointer disambiguates which adoption actually contributed. Also refresh running CSS animations' keyframe sets when style is recomputed. Previously only the first animation creation path set a keyframe set, so an existing animation never picked up newly inserted @keyframes rules.
2026-04-22 03:52:18 -03:00
void CascadedProperties::set_property(PropertyID property_id, NonnullRefPtr<StyleValue const> value, Important important, CascadeOrigin origin, Optional<FlyString> layer_name, GC::Ptr<CSS::CSSStyleDeclaration const> source, GC::Ptr<DOM::ShadowRoot const> source_shadow_root)
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 06:06:29 -03:00
{
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
m_contained_properties_cache.set(to_underlying(property_id), true);
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 06:06:29 -03:00
auto& entries = m_properties.ensure(property_id);
for (auto& entry : entries.in_reverse()) {
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
if (entry.origin == origin && entry.layer_name == layer_name && entry.source_shadow_root.ptr() == source_shadow_root) {
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 06:06:29 -03:00
if (entry.property.important == Important::Yes && important == Important::No)
return;
entry.property = StyleProperty {
.important = important,
.property_id = property_id,
.value = value,
};
LibWeb: Record cascaded properties relative order This will be required to perform logical alias mapping at compute time since we need to know the relative order of logical and physical property pairs
2026-03-15 08:12:25 -03:00
entry.cascade_index = m_next_cascade_index++;
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
entry.source = source.ptr();
entry.source_shadow_root = source_shadow_root.ptr();
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 06:06:29 -03:00
return;
}
}
entries.append(Entry {
.property = StyleProperty {
.important = important,
.property_id = property_id,
.value = value,
},
LibWeb: Record cascaded properties relative order This will be required to perform logical alias mapping at compute time since we need to know the relative order of logical and physical property pairs
2026-03-15 08:12:25 -03:00
.cascade_index = m_next_cascade_index++,
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 06:06:29 -03:00
.origin = origin,
.layer_name = move(layer_name),
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
.source = source.ptr(),
.source_shadow_root = source_shadow_root.ptr(),
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 06:06:29 -03: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 06:11:51 -03:00
RefPtr<StyleValue const> CascadedProperties::property(PropertyID property_id) 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 06:06:29 -03:00
{
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
if (!m_contained_properties_cache.get(to_underlying(property_id)))
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 06:06:29 -03:00
return nullptr;
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
return m_properties.get(property_id)->last().property.value;
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 06:06:29 -03:00
}
LibWeb: Map logical aliases at compute rather than cascade time This requires us to front load computation of writing-mode and direction before we encounter any logical aliases or their physical counterparts so that we can create a mapping context. Doing this at compute rather than cascade time achieves a few things: 1) Brings us into line with the spec 2) Avoids the double cascade that was previously required to compute mapping contexts 3) We now compute values of logical aliases, while `style_value_for_computed_property` maps logical aliases to their physical counterparts, this didn't account for all cases (i.e. if there was no layout node, Typed OM, etc). 4) Removes a hurdle to moving other upstream processes (i.e. arbitrary substitution function resolution, custom property computation) to compute time as the spec requires.
2026-03-16 01:51:24 -03:00
PropertyID CascadedProperties::property_with_higher_priority(PropertyID first_property_id, PropertyID second_property_id) const
{
if (!m_contained_properties_cache.get(to_underlying(first_property_id)))
return second_property_id;
if (!m_contained_properties_cache.get(to_underlying(second_property_id)))
return first_property_id;
if (m_properties.get(first_property_id)->last().cascade_index >= m_properties.get(second_property_id)->last().cascade_index)
return first_property_id;
return second_property_id;
}
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 06:06:29 -03:00
GC::Ptr<CSSStyleDeclaration const> CascadedProperties::property_source(PropertyID property_id) const
{
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
if (!m_contained_properties_cache.get(to_underlying(property_id)))
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 06:06:29 -03:00
return nullptr;
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
return m_properties.get(property_id)->last().source.ptr();
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 06:06:29 -03:00
}
LibWeb: Fix @keyframes resolution for slotted elements A @keyframes rule scoped to a shadow root was not reliably reached from an animated slotted light-DOM element: the keyframes lookup walked the element's own root first, then fell back to the document, but slotted elements can pick up animation-name from a ::slotted(...) rule that lives in an ancestor shadow root rather than in the element's own tree. Track the shadow-root scope that supplied each winning cascaded declaration, and use that scope to resolve the matching @keyframes when processing animation definitions. A shared constructable stylesheet can be adopted into several scopes at once, so the declaration object alone is too weak as a key; the per-entry shadow-root pointer disambiguates which adoption actually contributed. Also refresh running CSS animations' keyframe sets when style is recomputed. Previously only the first animation creation path set a keyframe set, so an existing animation never picked up newly inserted @keyframes rules.
2026-04-22 03:52:18 -03:00
GC::Ptr<DOM::ShadowRoot const> CascadedProperties::property_source_shadow_root(PropertyID property_id) const
{
if (!m_contained_properties_cache.get(to_underlying(property_id)))
return nullptr;
LibWeb: Make computed style data refcounted Move ComputedProperties and CascadedProperties out of the GC. They no longer contain strong references to GC-managed data. Keep computed styles alive from DOM elements and animation updates with RefPtr. Pass style into layout constructors by reference, since layout only copies the values it needs while building nodes. Use GC::Weak for cascade source links, so entries no longer keep the style declaration or shadow root alive.
2026-06-06 09:03:41 -03:00
return m_properties.get(property_id)->last().source_shadow_root.ptr();
LibWeb: Fix @keyframes resolution for slotted elements A @keyframes rule scoped to a shadow root was not reliably reached from an animated slotted light-DOM element: the keyframes lookup walked the element's own root first, then fell back to the document, but slotted elements can pick up animation-name from a ::slotted(...) rule that lives in an ancestor shadow root rather than in the element's own tree. Track the shadow-root scope that supplied each winning cascaded declaration, and use that scope to resolve the matching @keyframes when processing animation definitions. A shared constructable stylesheet can be adopted into several scopes at once, so the declaration object alone is too weak as a key; the per-entry shadow-root pointer disambiguates which adoption actually contributed. Also refresh running CSS animations' keyframe sets when style is recomputed. Previously only the first animation creation path set a keyframe set, so an existing animation never picked up newly inserted @keyframes rules.
2026-04-22 03:52:18 -03:00
}
LibWeb: Combine cascaded property lookups during computation Previously we would do two cascaded property lookups per property during style computation - the first to get the value of the property and the second to check whether it was marked as important. We now do this as a single lookup to save some unnecessary work.
2026-01-10 23:55:53 -03:00
Optional<StyleProperty> CascadedProperties::style_property(PropertyID property_id) 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 06:06:29 -03:00
{
LibWeb: Cache whether property is set on `CascadedProperties` This saves us having to access the HashMap in the common case there is no cascaded property
2026-01-26 23:25:59 -03:00
if (!m_contained_properties_cache.get(to_underlying(property_id)))
return {};
return m_properties.get(property_id)->last().property;
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 06:06:29 -03:00
}
}
Reference in a new issue Copy permalink