Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-12-08 06:09:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/DOM/AbstractElement.h

87 lines
3 KiB
C
Raw Normal View History

LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
/*
* Copyright (c) 2025, Sam Atkins <sam@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <LibGC/Cell.h>
LibWeb/DOM: Reduce AbstractElement.h's includes This doesn't need all of Selector.h and its various includes, it just needs the PseudoElement enum. StringStyleValue.h was transitively including ComponentValue.h through this, so it now includes it directly.
2025-09-09 13:37:30 +01:00
#include <LibWeb/CSS/PseudoElement.h>
#include <LibWeb/CSS/StyleProperty.h>
LibWeb/DOM: Stop including Element.h from AbstractElement.h We only need the forward declaration here, and this will let us include AbstractElement from Element.
2025-06-17 14:07:50 +01:00
#include <LibWeb/Forward.h>
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
namespace Web::DOM {
LibWeb/DOM: Rename ElementReference to AbstractElement This isn't some kind of identifier, it's a handle on an actual Element or PseudoElement.
2025-06-18 10:19:56 +01:00
// Either an Element or a PseudoElement
LibWeb/DOM: Expose AbstractElement outside of LibWeb This ends up used by the WebContent service's ConnectionFromClient in a later commit.
2025-09-07 14:27:04 +01:00
class WEB_API AbstractElement {
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
public:
LibWeb/DOM: Rename ElementReference to AbstractElement This isn't some kind of identifier, it's a handle on an actual Element or PseudoElement.
2025-06-18 10:19:56 +01:00
AbstractElement(GC::Ref<Element>, Optional<CSS::PseudoElement> = {});
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
LibWeb/DOM: Add document getter to AbstractElement
2025-07-10 12:19:28 +01:00
Document& document() const;
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
Element& element() { return m_element; }
Element const& element() const { return m_element; }
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
Optional<CSS::PseudoElement> pseudo_element() const { return m_pseudo_element; }
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
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
GC::Ptr<Layout::NodeWithStyle> layout_node();
GC::Ptr<Layout::NodeWithStyle const> layout_node() const { return const_cast<AbstractElement*>(this)->layout_node(); }
LibWeb: Pass `AbstractElement` in `ComputationContext` Passing the `AbstractElement` rather than the `TreeCountingFunctionResolutionContext` allows us to only compute the resolution context when necessary (i.e. when we actually need to resolve a tree counting function)
2025-10-22 00:06:38 +13:00
struct TreeCountingFunctionResolutionContext {
size_t sibling_count;
size_t sibling_index;
};
TreeCountingFunctionResolutionContext tree_counting_function_resolution_context() const;
LibWeb: Compute and propagate tree-counting function resolution context Tree counting functions should be resolved at style computation time - to do this we will need to know the element's sibling count and index. This commit computes that information and propagates it to the various `StyleValue::to_computed_value` methods.
2025-09-30 16:45:37 +13:00
LibWeb/DOM: Rename ElementReference to AbstractElement This isn't some kind of identifier, it's a handle on an actual Element or PseudoElement.
2025-06-18 10:19:56 +01:00
GC::Ptr<Element const> parent_element() const;
LibWeb: Return `AbstractElement` from `element_to_inherit_style_from` No functional changes.
2025-08-21 16:38:17 +12:00
Optional<AbstractElement> element_to_inherit_style_from() const;
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<AbstractElement> previous_in_tree_order() { return walk_layout_tree(WalkMethod::Previous); }
Optional<AbstractElement> previous_sibling_in_tree_order() { return walk_layout_tree(WalkMethod::PreviousSibling); }
bool is_before(AbstractElement const&) const;
LibWeb: Better CSS inheritance for nodes that represent a pseudo-element When we compute style for elements inside a UA-internal shadow tree that represent a pseudo-element (e.g ::placeholder), we actually run the StyleComputer machinery for (host element :: pseudo-element). While that lets us match the correct selectors, it was incorrectly applying CSS inheritance, since we'd also then inherit from whatever was above the host element in the tree. This patch fixes the issue by introducing an inheritance override in AbstractElement and then using that to force inheritance from whatever is actually directly above in the DOM for these elements instead of jumping all the way up past the host. This fixes an issue where `text-align: center` on input type=text elements would render the main text centered but placeholder text was still left-aligned.
2025-10-20 11:21:55 +02:00
void set_inheritance_override(GC::Ref<Element> element) { m_inheritance_override = element; }
LibWeb/DOM: Rename ElementReference to AbstractElement This isn't some kind of identifier, it's a handle on an actual Element or PseudoElement.
2025-06-18 10:19:56 +01:00
GC::Ptr<CSS::ComputedProperties const> computed_properties() const;
LibWeb: Store custom properties in an OrderedHashMap We are expected to preserve their order within a style declaration, so let's do that. Passes 1 tracked WPT subtest.
2025-09-18 11:44:56 +01:00
void set_custom_properties(OrderedHashMap<FlyString, CSS::StyleProperty>&& custom_properties);
[[nodiscard]] OrderedHashMap<FlyString, CSS::StyleProperty> const& custom_properties() const;
LibWeb: Move and rename CSSStyleValue to StyleValues/StyleValue.{h,cpp} This reverts 0e3487b9ab455a7648185995363bb3b487551d40. Back when I made that change, I thought we could make our StyleValue classes match the typed-om definitions directly. However, they have different requirements. Typed-om types need to be mutable and GCed, whereas StyleValues are immutable and ideally wouldn't require a JS VM. While I was already making such a cataclysmic change, I've moved it into the StyleValues directory, because it *not* being there has bothered me for a long time. 😅
2025-08-08 10:11:51 +01:00
RefPtr<CSS::StyleValue const> get_custom_property(FlyString const& name) const;
LibWeb/DOM: Add custom-property helpers to AbstractElement
2025-06-19 15:03:50 +01:00
LibWeb/DOM: Add CascadedProperties accessors to AbstractElement
2025-09-09 12:09:50 +01:00
GC::Ptr<CSS::CascadedProperties> cascaded_properties() const;
void set_cascaded_properties(GC::Ptr<CSS::CascadedProperties>);
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
bool has_non_empty_counters_set() const;
Optional<CSS::CountersSet const&> counters_set() const;
LibWeb/DOM: Rename ElementReference to AbstractElement This isn't some kind of identifier, it's a handle on an actual Element or PseudoElement.
2025-06-18 10:19:56 +01:00
CSS::CountersSet& ensure_counters_set();
void set_counters_set(OwnPtr<CSS::CountersSet>&&);
void visit(GC::Cell::Visitor& visitor) const;
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
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
String debug_description() const;
bool operator==(AbstractElement const&) const = default;
LibWeb: Add StyleScope to keep style caches per Document/ShadowRoot Before this change, we've been maintaining various StyleComputer caches at the document level. This made sense for old-school documents without shadow trees, since all the style information was document-wide anyway. However, documents with many shadow trees ended up suffering since any time you mutated a style sheet inside a shadow tree, *all* style caches for the entire document would get invalidated. This was particularly expensive on Reddit, which has tons of shadow trees with their own style elements. Every time we'd create one of their custom elements, we'd invalidate the document-level "rule cache" and have to rebuild it, taking about ~60ms each time (ouch). This commit introduces a new object called StyleScope. Every Document and ShadowRoot has its own StyleScope. Rule caches etc are moved from StyleComputer to StyleScope. Rule cache invalidation now happens at StyleScope level. As an example, rule cache rebuilds now take ~1ms on Reddit instead of ~60ms. This is largely a mechanical change, moving things around, but there's one key detail to be aware of: due to the :host selector, which works across the shadow DOM boundary and reaches from inside a shadow tree out into the light tree, there are various places where we have to check both the shadow tree's StyleScope *and* the document-level StyleScope in order to get all rules that may apply.
2025-11-13 19:08:08 +01:00
CSS::StyleScope const& style_scope() const;
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
private:
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
enum class WalkMethod : u8 {
Previous,
PreviousSibling,
};
Optional<AbstractElement> walk_layout_tree(WalkMethod);
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
GC::Ref<Element> m_element;
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
Optional<CSS::PseudoElement> m_pseudo_element;
LibWeb: Better CSS inheritance for nodes that represent a pseudo-element When we compute style for elements inside a UA-internal shadow tree that represent a pseudo-element (e.g ::placeholder), we actually run the StyleComputer machinery for (host element :: pseudo-element). While that lets us match the correct selectors, it was incorrectly applying CSS inheritance, since we'd also then inherit from whatever was above the host element in the tree. This patch fixes the issue by introducing an inheritance override in AbstractElement and then using that to force inheritance from whatever is actually directly above in the DOM for these elements instead of jumping all the way up past the host. This fixes an issue where `text-align: center` on input type=text elements would render the main text centered but placeholder text was still left-aligned.
2025-10-20 11:21:55 +02:00
GC::Ptr<Element> m_inheritance_override;
LibWeb/DOM: Introduce an ElementReference type We have the "Element, but also maybe a pseudo-element of it" concept in a lot of places, so let's wrap it up in a single type to make it easier to deal with.
2025-03-17 16:00:12 +00:00
};
}
LibWeb: Apply all animations and transitions before invalidating style This fixes an issue where only the last KeyframeEffect applied to an element would actually have an effect on the computed properties. It was particularly noticeable when animating a shorthand property like border-width, since only one of the border edges would have its width actually animate. By deferring the invalidation until all animations have been processed, we also reduce the amount of work that gets done on pages with many animations/transitions per element. Discord is very fond of this for example.
2025-07-18 11:56:00 +02:00
template<>
struct AK::Traits<Web::DOM::AbstractElement> : public DefaultTraits<Web::DOM::AbstractElement> {
static unsigned hash(Web::DOM::AbstractElement const& key)
{
return pair_int_hash(ptr_hash(&key.element()), key.pseudo_element().has_value() ? to_underlying(key.pseudo_element().value()) : -1);
}
};
Reference in a new issue Copy permalink