LadybirdBrowser/ladybird
1
1
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-09-21 18:37:58 +03:00
Code Issues Packages Projects Releases Wiki Activity
031296cf7b
ladybird/Userland/Libraries/LibWeb/CSS/StyleComputer.h

108 lines
3.6 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 11:38:21 +03:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
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 23:00:31 +03:00
* Copyright (c) 2021, Sam Atkins <atkinssj@serenityos.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 11:38:21 +03: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 11:24:48 +03: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 11:38:21 +03: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 18:47:59 +03: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 23:00:31 +03:00
#include <AK/HashMap.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 18:47:59 +03:00
#include <AK/NonnullRefPtrVector.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>
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-25 00:02:58 +03:00
#include <LibWeb/CSS/CSSStyleDeclaration.h>
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 15:32:12 +03:00
#include <LibWeb/CSS/Parser/StyleComponentValueRule.h>
LibWeb: Rename directory LibHTML => LibWeb Let's rename this to LibWeb since it aims to provide more parts of the web platform than just HTML. :^)
2020-03-07 12:32:51 +03:00
#include <LibWeb/CSS/StyleProperties.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 20:37:56 +03:00
#include <LibWeb/Forward.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 18:47:59 +03:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 21:01:35 +03:00
namespace Web::CSS {
LibWeb: Move everything into the Web namespace
2020-03-07 12:27:02 +03:00
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 01:44:26 +03:00
struct MatchingRule {
LibWeb: Rename StyleRule => CSSStyleRule This matches the CSSOM specification.
2021-03-07 17:00:02 +03:00
RefPtr<CSSStyleRule> rule;
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 01:44:26 +03:00
size_t style_sheet_index { 0 };
size_t rule_index { 0 };
size_t selector_index { 0 };
LibWeb: StyleResolver: Keep track of specificity of matched selector This way it gets easier to compare matches.
2021-05-25 00:01:24 +03:00
u32 specificity { 0 };
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 01:44:26 +03:00
};
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 23:00:31 +03:00
class PropertyDependencyNode : public RefCounted<PropertyDependencyNode> {
public:
static NonnullRefPtr<PropertyDependencyNode> create(String name)
{
return adopt_ref(*new PropertyDependencyNode(move(name)));
}
void add_child(NonnullRefPtr<PropertyDependencyNode>);
bool has_cycles();
private:
explicit PropertyDependencyNode(String name);
String m_name;
NonnullRefPtrVector<PropertyDependencyNode> m_children;
bool m_marked { false };
};
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 14:49:57 +03:00
class 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 18:47:59 +03:00
public:
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 14:49:57 +03:00
explicit StyleComputer(DOM::Document&);
~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 18:47:59 +03: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 20:37:56 +03:00
DOM::Document& document() { return m_document; }
LibWeb: Convert StyleResolver.{h,cpp} to east const
2021-07-14 18:56:11 +03: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 18:47:59 +03:00
LibWeb: Give DOM::Document some default style properties Add StyleResolver::create_document_style() to help in creating an "empty" style with nothing but default values.
2021-09-23 20:48:41 +03:00
NonnullRefPtr<StyleProperties> create_document_style() const;
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 14:49:57 +03:00
NonnullRefPtr<StyleProperties> compute_style(DOM::Element&) 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 18:47:59 +03:00
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 12:38:18 +03:00
// https://www.w3.org/TR/css-cascade/#origin
enum class CascadeOrigin {
Any, // FIXME: This is not part of the spec. Get rid of it.
Author,
User,
UserAgent,
Animation,
Transition,
};
Vector<MatchingRule> collect_matching_rules(DOM::Element const&, CascadeOrigin = CascadeOrigin::Any) 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 21:40:21 +03: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 19:49:50 +03:00
void invalidate_rule_cache();
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 18:47:59 +03:00
private:
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 12:38:18 +03:00
void compute_cascaded_values(StyleProperties&, DOM::Element&) const;
LibWeb: Give DOM::Document some default style properties Add StyleResolver::create_document_style() to help in creating an "empty" style with nothing but default values.
2021-09-23 20:48:41 +03:00
void compute_font(StyleProperties&, DOM::Element const*) const;
void compute_defaulted_values(StyleProperties&, DOM::Element const*) const;
void absolutize_values(StyleProperties&, DOM::Element const*) const;
LibWeb: Teach StyleComputer about "Automatic Box Type Transformation" CSS has rules about automatic blockification or inlinification of boxes in certain circumstances. This patch implements automatic blockification of absolutely positioned and floating elements. This makes the smile appear on ACID2. :^)
2022-01-24 16:41:48 +03:00
void transform_box_type_if_needed(StyleProperties&, DOM::Element const&) const;
LibWeb: Start absolutizing lengths after performing the CSS cascade Once we've performed the cascade on a set of values for an element, we should have enough information to resolve/absolutize some lengths. Basically, any CSS length that isn't "auto" or a percentage can be turned into an absolute length (in pixels) as long as we have the following information: - The viewport rect - The parent element's font - The document element's font - The element's own font To ensure that we can absolutize lengths relative to the element's own font, we now do a separate first pass where font-related properties are defaulted (in the cascade spec sense of the word) and become usable. There's a lot more work to do here, but this should open up a lot of simplification in layout code, since it will no longer need to care about relative lengths. Layout still needs to resolve percentages, since we can't do that for some properties until the containing block dimensions are known.
2021-09-23 14:13:51 +03:00
LibWeb: Give DOM::Document some default style properties Add StyleResolver::create_document_style() to help in creating an "empty" style with nothing but default values.
2021-09-23 20:48:41 +03:00
void compute_defaulted_property_value(StyleProperties&, DOM::Element const*, CSS::PropertyID) 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 12:38:18 +03:00
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 19:04:31 +03:00
RefPtr<StyleValue> resolve_unresolved_style_value(DOM::Element&, PropertyID, UnresolvedStyleValue const&, HashMap<String, StyleProperty const*> const&) const;
bool expand_unresolved_values(DOM::Element&, StringView property_name, HashMap<String, NonnullRefPtr<PropertyDependencyNode>>& dependencies, Vector<StyleComponentValueRule> const& source, Vector<StyleComponentValueRule>& dest, size_t source_start_index, HashMap<String, StyleProperty const*> const& custom_properties) const;
LibWeb: Parse and resolve UnresolvedStyleValues If a property is custom or contains a `var()` reference, it cannot be parsed into a proper StyleValue immediately, so we store it as an UnresolvedStyleValue until the property is compute. Then, at compute time, we resolve them by expanding out any `var()` references, and parsing the result. The implementation here is very naive, and involves copying the UnresolvedStyleValue's tree of StyleComponentValueRules while copying the contents of any `var()`s it finds along the way. This is quite an expensive operation to do every time that the style is computed.
2021-12-03 15:32:12 +03: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 10:01:12 +03: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 12:38:18 +03:00
void for_each_stylesheet(CascadeOrigin, Callback) const;
struct MatchingRuleSet {
Vector<MatchingRule> user_agent_rules;
Vector<MatchingRule> author_rules;
};
LibWeb: Perform CSS custom property cascade once instead of per-property Previously we would re-run the entire CSS selector machinery for each property resolved. Instead of doing that, we now resolve a final set of custom property key/value pairs at the start of the cascade.
2022-02-10 19:04:31 +03:00
void cascade_declarations(StyleProperties&, DOM::Element&, Vector<MatchingRule> const&, CascadeOrigin, bool important, HashMap<String, StyleProperty const*> const&) 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 10:01:12 +03: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 19:49:50 +03:00
void build_rule_cache();
void build_rule_cache_if_needed() const;
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 20:37:56 +03:00
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 19:49:50 +03:00
struct RuleCache {
LibWeb: Add "ID" buckets to StyleComputer::RuleCache We can skip rules that require a specific ID when matching against any element that doesn't have that ID.
2022-02-10 20:50:58 +03:00
HashMap<FlyString, Vector<MatchingRule>> rules_by_id;
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 19:49:50 +03:00
HashMap<FlyString, Vector<MatchingRule>> rules_by_class;
Vector<MatchingRule> other_rules;
int generation { 0 };
};
OwnPtr<RuleCache> m_rule_cache;
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 18:47:59 +03:00
};
LibWeb: Move everything into the Web namespace
2020-03-07 12:27:02 +03:00
}
Reference in New Issue Copy Permalink