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

69 lines
2.1 KiB
C
Raw Permalink Normal View History

LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
/*
* Copyright (c) 2026, Sam Atkins <sam@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/FlyString.h>
#include <AK/Optional.h>
#include <LibWeb/CSS/CSSConditionRule.h>
LibWeb: Evaluate container queries when collecting matching style rules MatchingRules now have a container_rule member which stores the nearest ancestor CSSContainerRule, if any. When populating the rule cache, we maintain a stack of CSSContainerRules that we are within, and use record the last one on the MatchingRule, so that it's O(1) instead of having to walk up the rule's ancestors each time. This does mean we have reimplement some "for each rule" code. When collecting rules to apply to an element, we see if the MatchingRule has a container_rule, and if so, we evaluate that rule's query to see if the element has a matching container. We then also match any ancestor container rules, using the cached parent container rule. Add a custom test to cover the case of nested name-only `@container`s, which WPT lacks currently as far as I can tell.
2026-05-08 11:57:57 -03:00
#include <LibWeb/Forward.h>
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
namespace Web::CSS {
// https://drafts.csswg.org/css-conditional-5/#dictdef-csscontainercondition
struct CSSContainerCondition {
String name;
String query;
};
// https://drafts.csswg.org/css-conditional-5/#the-csscontainerrule-interface
class CSSContainerRule final : public CSSConditionRule {
WEB_PLATFORM_OBJECT(CSSContainerRule, CSSConditionRule);
GC_DECLARE_ALLOCATOR(CSSContainerRule);
public:
struct Condition {
Optional<FlyString> container_name;
RefPtr<ContainerQuery> container_query;
};
[[nodiscard]] static GC::Ref<CSSContainerRule> create(JS::Realm&, Vector<Condition>&&, CSSRuleList&);
virtual ~CSSContainerRule() override;
virtual String condition_text() const override;
virtual bool condition_matches() const override;
LibWeb: Evaluate container queries when collecting matching style rules MatchingRules now have a container_rule member which stores the nearest ancestor CSSContainerRule, if any. When populating the rule cache, we maintain a stack of CSSContainerRules that we are within, and use record the last one on the MatchingRule, so that it's O(1) instead of having to walk up the rule's ancestors each time. This does mean we have reimplement some "for each rule" code. When collecting rules to apply to an element, we see if the MatchingRule has a container_rule, and if so, we evaluate that rule's query to see if the element has a matching container. We then also match any ancestor container rules, using the cached parent container rule. Add a custom test to cover the case of nested name-only `@container`s, which WPT lacks currently as far as I can tell.
2026-05-08 11:57:57 -03:00
bool matches(DOM::AbstractElement const&) const;
LibWeb: Parse and evaluate `@container` `<size-feature>`s e.g., `@container (width >= 300px) {}` and similar. During style computation, flag any elements whose style depends on a size container. Then re-evaluate their style after the initial layout has been computed and size containers have a size. This may take multiple passes, as these may have further descendants that depend on their size, etc. We limit this to 8 passes currently. SizeFeature itself is very similar to MediaFeature, but queries the container element instead. There are only 6 size features specified, so they're hard-coded instead of generated from JSON. Also add a counter test for the narrower restyle path.
2026-05-14 08:46:17 -03:00
bool contains_size_feature() const;
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
String container_name() const;
String container_query() const;
// FIXME: Should be FrozenArray
Vector<CSSContainerCondition> conditions() const;
virtual void for_each_effective_rule(TraversalOrder, Function<void(CSSRule const&)> const& callback) const override;
private:
CSSContainerRule(JS::Realm&, Vector<Condition>&&, CSSRuleList&);
virtual void initialize(JS::Realm&) override;
LibWeb/CSS: Cache CSSContainerRule's nearest ancestor CSSContainerRule Once we start evaluating `@container` matches, we will need to check if any ancestor `@container`s also match. Caching the nearest one, if any, will let us skip walking the entire ancestor chain.
2026-05-08 13:42:15 -03:00
virtual void visit_edges(Cell::Visitor&) override;
virtual void clear_caches() override;
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
virtual String serialized() const override;
LibWeb/CSS: Cache CSSContainerRule's nearest ancestor CSSContainerRule Once we start evaluating `@container` matches, we will need to check if any ancestor `@container`s also match. Caching the nearest one, if any, will let us skip walking the entire ancestor chain.
2026-05-08 13:42:15 -03:00
CSSContainerRule const* find_parent_container_rule() const;
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
LibWeb: Evaluate container queries when collecting matching style rules MatchingRules now have a container_rule member which stores the nearest ancestor CSSContainerRule, if any. When populating the rule cache, we maintain a stack of CSSContainerRules that we are within, and use record the last one on the MatchingRule, so that it's O(1) instead of having to walk up the rule's ancestors each time. This does mean we have reimplement some "for each rule" code. When collecting rules to apply to an element, we see if the MatchingRule has a container_rule, and if so, we evaluate that rule's query to see if the element has a matching container. We then also match any ancestor container rules, using the cached parent container rule. Add a custom test to cover the case of nested name-only `@container`s, which WPT lacks currently as far as I can tell.
2026-05-08 11:57:57 -03:00
bool conditions_match(DOM::AbstractElement const&) const;
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
Vector<Condition> m_conditions;
LibWeb/CSS: Cache CSSContainerRule's nearest ancestor CSSContainerRule Once we start evaluating `@container` matches, we will need to check if any ancestor `@container`s also match. Caching the nearest one, if any, will let us skip walking the entire ancestor chain.
2026-05-08 13:42:15 -03:00
mutable GC::Ptr<CSSContainerRule const> m_cached_parent_container_rule;
mutable bool m_parent_container_rule_cache_valid { false };
LibWeb/CSS: Implement CSSContainerRule No parsing yet, just CSSContainerRule and the supporting ContainerQuery class. CSSContainerRule is unusual in how it matches, because instead of it either matching or not matching globally, it instead is matched against a specific element. But also, some at-rules inside it always apply, as if they were written outside it. This doesn't fit well with how CSSConditionRule is implemented, and will likely require some rework later. For now, `condition_matches()` always returns false, and `for_each_effective_rule()` is overridden to always process those global at-rules and nothing else.
2026-03-27 11:14:00 -03:00
};
template<>
inline bool CSSRule::fast_is<CSSContainerRule>() const { return type() == CSSRule::Type::Container; }
}
Reference in a new issue Copy permalink