Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/CSS/CountersSet.h

60 lines
1.8 KiB
C
Raw Normal View History

LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
/*
LibWeb: Make [resolve,inherit]_counters() take AbstractElement This is one of those cases where the spec says "element" and means "element or pseudo-element". The easiest way to handle both is to make these be free functions that take an AbstractElement, and then give AbstractElement some helper methods so that the caller doesn't have to care which it's dealing with. There are some FIXMEs here because PseudoElement doesn't have a CountersSet yet, and because the CountersSet currently uses a UniqueNodeID to identify counter sources, which doesn't support pseudo-elements.
2025-06-18 10:28:56 +01:00
* Copyright (c) 2024-2025, Sam Atkins <sam@ladybird.org>
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Checked.h>
#include <AK/FlyString.h>
#include <AK/Optional.h>
LibWeb: Support counter-* properties on pseudo-elements There are multiple things happening here which are interconnected: - We now use AbstractElement to refer to the source of a counter, which means we also need to pass that around to compute `content`. - Give AbstractElement new helper methods that are needed by CountersSet, so it doesn't have to care whether it's dealing with a true Element or PseudoElement. - The CountersSet algorithms now walk the layout tree instead of DOM tree, so TreeBuilder needs to wait until the layout node exists before it resolves counters for it. - Resolve counters when creating a pseudo-element's layout node. We awkwardly compute the `content` value up to twice: Once to figure out what kind of node we need to make, and then if it's a string, we do so again after counters are resolved so we can get the true value of any `counter()` functions. This will need adjusting in the future but it works for now.
2025-06-17 16:33:23 +01:00
#include <LibWeb/DOM/AbstractElement.h>
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
#include <LibWeb/Forward.h>
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
namespace Web::CSS {
// "UAs may have implementation-specific limits on the maximum or minimum value of a counter.
// If a counter reset, set, or increment would push the value outside of that range, the value
// must be clamped to that range." - https://drafts.csswg.org/css-lists-3/#auto-numbering
// So, we use a Checked<i32> and saturating addition/subtraction.
using CounterValue = Checked<i32>;
// https://drafts.csswg.org/css-lists-3/#counter
struct Counter {
FlyString name;
LibWeb: Support counter-* properties on pseudo-elements There are multiple things happening here which are interconnected: - We now use AbstractElement to refer to the source of a counter, which means we also need to pass that around to compute `content`. - Give AbstractElement new helper methods that are needed by CountersSet, so it doesn't have to care whether it's dealing with a true Element or PseudoElement. - The CountersSet algorithms now walk the layout tree instead of DOM tree, so TreeBuilder needs to wait until the layout node exists before it resolves counters for it. - Resolve counters when creating a pseudo-element's layout node. We awkwardly compute the `content` value up to twice: Once to figure out what kind of node we need to make, and then if it's a string, we do so again after counters are resolved so we can get the true value of any `counter()` functions. This will need adjusting in the future but it works for now.
2025-06-17 16:33:23 +01:00
DOM::AbstractElement originating_element; // "creator"
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
bool reversed { false };
Optional<CounterValue> value;
};
// https://drafts.csswg.org/css-lists-3/#css-counters-set
class CountersSet {
public:
CountersSet() = default;
~CountersSet() = default;
LibWeb: Support counter-* properties on pseudo-elements There are multiple things happening here which are interconnected: - We now use AbstractElement to refer to the source of a counter, which means we also need to pass that around to compute `content`. - Give AbstractElement new helper methods that are needed by CountersSet, so it doesn't have to care whether it's dealing with a true Element or PseudoElement. - The CountersSet algorithms now walk the layout tree instead of DOM tree, so TreeBuilder needs to wait until the layout node exists before it resolves counters for it. - Resolve counters when creating a pseudo-element's layout node. We awkwardly compute the `content` value up to twice: Once to figure out what kind of node we need to make, and then if it's a string, we do so again after counters are resolved so we can get the true value of any `counter()` functions. This will need adjusting in the future but it works for now.
2025-06-17 16:33:23 +01:00
Counter& instantiate_a_counter(FlyString name, DOM::AbstractElement const&, bool reversed, Optional<CounterValue>);
void set_a_counter(FlyString name, DOM::AbstractElement const&, CounterValue value);
void increment_a_counter(FlyString name, DOM::AbstractElement const&, CounterValue amount);
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
void append_copy(Counter const&);
Optional<Counter&> last_counter_with_name(FlyString const& name);
LibWeb: Support counter-* properties on pseudo-elements There are multiple things happening here which are interconnected: - We now use AbstractElement to refer to the source of a counter, which means we also need to pass that around to compute `content`. - Give AbstractElement new helper methods that are needed by CountersSet, so it doesn't have to care whether it's dealing with a true Element or PseudoElement. - The CountersSet algorithms now walk the layout tree instead of DOM tree, so TreeBuilder needs to wait until the layout node exists before it resolves counters for it. - Resolve counters when creating a pseudo-element's layout node. We awkwardly compute the `content` value up to twice: Once to figure out what kind of node we need to make, and then if it's a string, we do so again after counters are resolved so we can get the true value of any `counter()` functions. This will need adjusting in the future but it works for now.
2025-06-17 16:33:23 +01:00
Optional<Counter&> counter_with_same_name_and_creator(FlyString const& name, DOM::AbstractElement const&);
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
Vector<Counter> const& counters() const { return m_counters; }
bool is_empty() const { return m_counters.is_empty(); }
LibWeb: Support counter-* properties on pseudo-elements There are multiple things happening here which are interconnected: - We now use AbstractElement to refer to the source of a counter, which means we also need to pass that around to compute `content`. - Give AbstractElement new helper methods that are needed by CountersSet, so it doesn't have to care whether it's dealing with a true Element or PseudoElement. - The CountersSet algorithms now walk the layout tree instead of DOM tree, so TreeBuilder needs to wait until the layout node exists before it resolves counters for it. - Resolve counters when creating a pseudo-element's layout node. We awkwardly compute the `content` value up to twice: Once to figure out what kind of node we need to make, and then if it's a string, we do so again after counters are resolved so we can get the true value of any `counter()` functions. This will need adjusting in the future but it works for now.
2025-06-17 16:33:23 +01:00
void visit_edges(GC::Cell::Visitor&);
String dump() const;
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
private:
Vector<Counter> m_counters;
};
LibWeb: Make [resolve,inherit]_counters() take AbstractElement This is one of those cases where the spec says "element" and means "element or pseudo-element". The easiest way to handle both is to make these be free functions that take an AbstractElement, and then give AbstractElement some helper methods so that the caller doesn't have to care which it's dealing with. There are some FIXMEs here because PseudoElement doesn't have a CountersSet yet, and because the CountersSet currently uses a UniqueNodeID to identify counter sources, which doesn't support pseudo-elements.
2025-06-18 10:28:56 +01:00
void resolve_counters(DOM::AbstractElement&);
void inherit_counters(DOM::AbstractElement&);
LibWeb: Give DOM Elements a CountersSet This represents each element's set of CSS counters. https://drafts.csswg.org/css-lists-3/#css-counters-set Counters are resolved while building the tree. Most elements will not have any counters to keep track of, so as an optimization, we don't create a CountersSet object until the element actually needs one. In order to properly support counters on pseudo-elements, the CountersSet needs to go somewhere else. However, my experiments with placing it on the Layout::Node kept hitting a wall. For now, this is fairly simple at least.
2024-07-17 11:46:08 +01:00
}
Reference in a new issue Copy permalink