Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/Node.h

364 lines
13 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 09:38:21 +01:00
/*
LibWeb: Move "needs layout update" flag from DOM to layout tree This is in preparation for allowing anonymous boxes to retain their intrinsic size cache across layouts.
2025-04-18 20:40:14 +02:00
* Copyright (c) 2018-2025, Andreas Kling <andreas@ladybird.org>
LibWeb: Factor out conditions for creation of inline continuation Having one big `if` to determine whether or not we should restructure an inline layout node became a bit unwieldy. This extracts the logic into a separate method.
2025-02-19 10:54:44 +01:00
* Copyright (c) 2025, Jelle Raaijmakers <jelle@ladybird.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 09:38:21 +01: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 01:24:48 -07: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 09:38:21 +01:00
*/
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
#pragma once
AK: Rename RetainPtr.h => RefPtr.h, Retained.h => NonnullRefPtr.h.
2019-06-21 18:45:35 +02:00
#include <AK/NonnullRefPtr.h>
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
#include <AK/Vector.h>
LibJS+LibWeb: Move headers around to allow including Value from Cell The goal here is to allow Cell::initialize to return a ThrowCompletion, to handle OOM for example. Cell.h will then need to include Completion.h which must include Value.h. This currently can't happen because Value.h includes BigInt.h, which in turn includes Cell.h. So we would have an include cycle. This removes BigInt.h from Value.h, as it is forward-declarable (it is only referred to with a reference or pointer). Then the Value overload for Cell::Visitor::visit is moved to Cell.h, and missing BigInt.h includes as peppered as needed.
2023-01-28 11:26:03 -05:00
#include <LibJS/Heap/Cell.h>
LibWeb: Add missing visit_edges() for ImageStyleValue ImageStyleValue has a visit_edges() method, although it is not a GC-allocated object. This is necessary because it owns a GC-allocated ImageRequest that we want to visit, instead of using JS::Handle, to avoid leaks. In the future, we might want to make StyleValue be GC-allocated. For now, this change adds missing visit_edges() calls for objects that own ImageStyleValue.
2023-09-28 00:26:02 +02:00
#include <LibWeb/CSS/StyleValues/ImageStyleValue.h>
LibWeb: Make FontCache per-StyleComputer This effectively makes it per-Document, but we hang it off of StyleComputer since that's what it's used for. The purpose of this is to prevent downloaded fonts from escaping the context that loaded them. There's probably a more elegant solution where we still share caching of system fonts, but let's start here.
2023-08-17 18:51:32 +02:00
#include <LibWeb/DOM/Document.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
#include <LibWeb/Export.h>
LibWeb: Add some iteration helpers to LayoutNode - for_each_child_of_type<T> - previous_sibling_of_type<T>
2020-06-09 20:42:11 +02:00
#include <LibWeb/Forward.h>
LibWeb: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 23:07:26 +02:00
#include <LibWeb/Painting/DisplayListRecordingContext.h>
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
#include <LibWeb/Painting/Paintable.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 10:32:51 +01:00
#include <LibWeb/TreeNode.h>
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
namespace Web::Layout {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 13:38:18 +01:00
enum class LayoutMode {
LibWeb: Express intrinsic size layout via size constraints Previously, we had three layout modes: - Normal: - Everything uses the computed values from CSS. - MinContent: - Containing blocks act as if they have 0 width. - All line breaking opportunities are taken. - MaxContent: - Containing blocks act as if they have infinite width. - Only forced line breaks are accepted. The above was based on a set of misunderstandings of CSS sizing. A major problem with the above was that *all* containing blocks behaved differently during intrinsic size layout, not just the relevant one. With this patch there are only two layout modes: - Normal: - Everything uses the computed values from CSS. - IntrinsicSizeDetermination: - One or more boxes have size constraints applied. There are two size constraints per layout box, set here: - FormattingState::NodeState::width_constraint - FormattingState::NodeState::height_constraint They are of type SizeConstraint and can be one of None, MinContent, or MaxContent. The default is None. When performing an IntrinsicSizeDetermination layout, we now assign a size constraint to the box we're trying to determine the intrinsic size of, which is then honored by using two new helpers to query the dimensions of containing blocks: - FormattingContext::containing_block_width_for(Box) - FormattingContext::containing_block_height_for(Box) If there's a relevant constraint in effect on the Box, the size of its containing block is adjusted accordingly. This is essentially an implementation of the "available space" constraints from CSS-SIZING-3. I'm sure some things will break from this, and we'll have to deal with that separately. Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-09 15:17:47 +02:00
// Normal layout. No min-content or max-content constraints applied.
LibWeb: Rename the LayoutMode enum values and explain them The old mode names, while mechanically accurate, didn't really reflect their relationship to the CSS specifications. This patch renames them as follows: Default => Normal AllPossibleLineBreaks => MinContent OnlyRequiredLineBreaks => MaxContent There's also now an explainer comment with the LayoutMode enum about the specific implications of layout in each mode.
2022-03-19 15:44:02 +01:00
Normal,
LibWeb: Express intrinsic size layout via size constraints Previously, we had three layout modes: - Normal: - Everything uses the computed values from CSS. - MinContent: - Containing blocks act as if they have 0 width. - All line breaking opportunities are taken. - MaxContent: - Containing blocks act as if they have infinite width. - Only forced line breaks are accepted. The above was based on a set of misunderstandings of CSS sizing. A major problem with the above was that *all* containing blocks behaved differently during intrinsic size layout, not just the relevant one. With this patch there are only two layout modes: - Normal: - Everything uses the computed values from CSS. - IntrinsicSizeDetermination: - One or more boxes have size constraints applied. There are two size constraints per layout box, set here: - FormattingState::NodeState::width_constraint - FormattingState::NodeState::height_constraint They are of type SizeConstraint and can be one of None, MinContent, or MaxContent. The default is None. When performing an IntrinsicSizeDetermination layout, we now assign a size constraint to the box we're trying to determine the intrinsic size of, which is then honored by using two new helpers to query the dimensions of containing blocks: - FormattingContext::containing_block_width_for(Box) - FormattingContext::containing_block_height_for(Box) If there's a relevant constraint in effect on the Box, the size of its containing block is adjusted accordingly. This is essentially an implementation of the "available space" constraints from CSS-SIZING-3. I'm sure some things will break from this, and we'll have to deal with that separately. Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-09 15:17:47 +02:00
// Intrinsic size determination.
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
// Boxes honor min-content and max-content constraints (set via LayoutState::UsedValues::{width,height}_constraint)
LibWeb: Express intrinsic size layout via size constraints Previously, we had three layout modes: - Normal: - Everything uses the computed values from CSS. - MinContent: - Containing blocks act as if they have 0 width. - All line breaking opportunities are taken. - MaxContent: - Containing blocks act as if they have infinite width. - Only forced line breaks are accepted. The above was based on a set of misunderstandings of CSS sizing. A major problem with the above was that *all* containing blocks behaved differently during intrinsic size layout, not just the relevant one. With this patch there are only two layout modes: - Normal: - Everything uses the computed values from CSS. - IntrinsicSizeDetermination: - One or more boxes have size constraints applied. There are two size constraints per layout box, set here: - FormattingState::NodeState::width_constraint - FormattingState::NodeState::height_constraint They are of type SizeConstraint and can be one of None, MinContent, or MaxContent. The default is None. When performing an IntrinsicSizeDetermination layout, we now assign a size constraint to the box we're trying to determine the intrinsic size of, which is then honored by using two new helpers to query the dimensions of containing blocks: - FormattingContext::containing_block_width_for(Box) - FormattingContext::containing_block_height_for(Box) If there's a relevant constraint in effect on the Box, the size of its containing block is adjusted accordingly. This is essentially an implementation of the "available space" constraints from CSS-SIZING-3. I'm sure some things will break from this, and we'll have to deal with that separately. Spec: https://drafts.csswg.org/css-sizing-3/#available
2022-07-09 15:17:47 +02:00
// by considering their containing block to be 0-sized or infinitely large in the relevant axis.
LibWeb: Rename IntrinsicSizeDetermination to IntrinsicSizing This matches the exact terminology used in CSS-SIZING-3: https://drafts.csswg.org/css-sizing-3/#intrinsic-sizing
2022-07-20 18:12:12 +02:00
// https://drafts.csswg.org/css-sizing-3/#intrinsic-sizing
IntrinsicSizing,
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 13:38:18 +01:00
};
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API Node
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
: public JS::Cell
LibJS: Make JS::Cell a Weakable This makes things easier downstream of Cell, and is preparation for using weak pointers in prototype chain property caches.
2024-05-02 10:24:23 +02:00
, public TreeNode<Node> {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(Node, JS::Cell);
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
public:
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
virtual ~Node();
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 13:42:07 +02:00
bool is_anonymous() const;
DOM::Node const* dom_node() const;
DOM::Node* dom_node();
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Add info about pseudo element type in Layout::Node
2023-08-06 01:29:55 +02:00
DOM::Element const* pseudo_element_generator() const;
DOM::Element* pseudo_element_generator();
LibWeb: Move "needs layout update" flag from DOM to layout tree This is in preparation for allowing anonymous boxes to retain their intrinsic size cache across layouts.
2025-04-18 20:40:14 +02:00
bool needs_layout_update() const { return m_needs_layout_update; }
void set_needs_layout_update(DOM::SetNeedsLayoutReason);
void reset_needs_layout_update() { m_needs_layout_update = false; }
LibWeb: Generate an enum for generated pseudo-elements
2025-03-19 15:52:33 +00:00
bool is_generated() const { return m_generated_for.has_value(); }
LibWeb/Layout: Expose which pseudo-element a node was generated for
2025-06-17 16:21:12 +01:00
Optional<CSS::PseudoElement> generated_for_pseudo_element() const { return m_generated_for; }
LibWeb: Remove GeneratedPseudoElement enum This doesn't currently provide any value over just using PseudoElement, and makes it harder to work with PseudoElement in other places.
2025-06-05 17:18:12 +01:00
bool is_generated_for_before_pseudo_element() const { return m_generated_for == CSS::PseudoElement::Before; }
bool is_generated_for_after_pseudo_element() const { return m_generated_for == CSS::PseudoElement::After; }
bool is_generated_for_backdrop_pseudo_element() const { return m_generated_for == CSS::PseudoElement::Backdrop; }
void set_generated_for(CSS::PseudoElement type, DOM::Element& element)
LibWeb: Add info about pseudo element type in Layout::Node
2023-08-06 01:29:55 +02:00
{
m_generated_for = type;
m_pseudo_element_generator = &element;
}
LibWeb: Create flex items for empty generated boxes I couldn't find anything in the specs about this, but GMail uses empty generated boxes (`::before` and `::after` with `content: ""`) inside a flexbox container in order to vertically center things. The flexbox spec tells us to not generate flex items for empty *anonymous* boxes, so we continue not doing that, but generated boxes (any pseudo-element box) now always produce a flex item. This probably isn't perfect either, and we'll have to revisit it for stuff like `::first-letter`.
2022-09-28 17:11:23 +02:00
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
using PaintableList = IntrusiveList<&Painting::Paintable::m_list_node>;
LibWeb: Rename Layout::Node::paintable() to first_paintable() Layout node is allowed to have multiple corresponding paintables, so first_paintable() is more explicit name for getter that returns first paintable.
2024-10-16 15:19:32 +02:00
Painting::Paintable* first_paintable() { return m_paintable.first(); }
Painting::Paintable const* first_paintable() const { return m_paintable.first(); }
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
PaintableList& paintables() { return m_paintable; }
PaintableList const& paintables() const { return m_paintable; }
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
void add_paintable(GC::Ptr<Painting::Paintable>);
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
void clear_paintables();
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
virtual GC::Ptr<Painting::Paintable> create_paintable() const;
LibWeb: Split Paintable into Paintable and PaintableBox To prepare for paintable inline content, we take the basic painting functionality and hoist it into a base class.
2022-03-10 15:50:57 +01:00
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 13:42:07 +02:00
DOM::Document& document();
DOM::Document const& document() const;
LibHTML: Add LayoutNode::document() for easy access Every LayoutNode indirectly belongs to some Document. For anonymous LayoutNodes, we simply traverse the parent chain until we find someone with a Node from which we can get a Document&.
2019-09-29 11:43:33 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<HTML::Navigable> navigable() const;
LibWeb: Change viewport ownership from `BrowsingContext` to `Navigable`
2023-08-22 16:00:42 +02:00
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
Viewport const& root() const;
Viewport& root();
LibHTML: Add a convenient way to get from any layout node to the root
2019-11-04 19:37:52 +01:00
LibWeb: Add Layout::Node::is_root_element() This returns true if the layout node corresponds to the <html> element.
2020-12-05 20:10:02 +01:00
bool is_root_element() const;
LibWeb: Remove a bunch of calls to `to_byte_string` A bunch of this is leftover from pre porting over to new AK::String. For example, for functions which previously took a ByteString const& now accepting a StringView.
2024-04-05 09:26:03 +02:00
String debug_description() const;
LibWeb: Demangle the names returned by Layout::Node::class_name() Note that these are only used in debugging/test output so it's not performance sensitive.
2021-01-01 16:42:44 +01:00
LibHTML: Add is<T> and to<T> helpers for LayoutNode class family
2019-10-15 14:19:52 +02:00
bool has_style() const { return m_has_style; }
LibWeb: Verify that a node has styled properties in its styled accessors For example, it's possible to access Node::computed_values() on a node that neither has style nor a parent with style. This ultimately results in a null pointer dereference when we return parent()->computed_values() as a fallback. This can be a little tricky to track down due to these functions being inlined, so add an explicit verification.
2023-04-27 09:03:49 -04:00
bool has_style_or_parent_with_style() const;
LibHTML: Flesh out <img> element with LayoutImage and LayoutReplaced This patch adds parsing of <img> into HTMLImageElement objects. It also adds LayoutImage and its parent class LayoutReplaced, which is going to represent CSS "replaced elements."
2019-10-05 22:07:45 +02:00
LibWeb: Allow <svg> layout boxes to have children We can't say that "no replaced boxes can have children", since that breaks SVG. Instead, let each LayoutNode decide whether it's allowed to have children. Fixes #4223.
2020-11-29 15:29:10 +01:00
virtual bool can_have_children() const { return true; }
LibWeb: Add Layout::Node::display() This will return something sensible for style-less nodes as well.
2022-10-06 15:33:09 +02:00
CSS::Display display() const;
LibWeb: Honor CSS display value in is_inline() and is_inline_block() These were totally ad-hoc before, is_inline() was based on a boolean flag on Layout::Node that we set in various situations. Meanwhile, is_inline_block() was a combination on is_inline() plus a type check to see if the layout node inherited from BlockContainer. This patch replaces the above mess with simple lookups of the CSS display value. Note that layout nodes without their own style (i.e text nodes) are automatically assumed to be inline and non-blocks. This has to be special-cased since layout nodes without style will consult the style of their parent, so without short-circuiting this would break.
2022-10-06 14:39:11 +02:00
bool is_inline() const;
LibWeb: Remove hand-rolled is_foo() helpers in Layout::Node classes
2021-01-01 18:55:47 +01:00
bool is_inline_block() const;
LibWeb: Output display type inline-table in layout dump
2023-01-16 13:51:49 +01:00
bool is_inline_table() const;
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
LibWeb: Don't relocate fragments across atomic inline boundary All fragments inside an atomic inline box should stay within that box, otherwise we'll screw up the paint order and paint them behind things that they're supposed to be on top of. This fixes an issue with inline-block content not appearing on sites like Google Docs and Reddit, among others.
2025-08-24 17:34:46 +02:00
bool is_atomic_inline() const;
LibWeb: Move Layout::Box::is_out_of_flow() to Layout::Node I want to use this function in inline layout, where we're not just dealing with boxes.
2022-03-22 18:34:02 +01:00
bool is_out_of_flow(FormattingContext const&) const;
LibWeb: Add fast_is<T>() for some DOM and layout node subclasses The generic is<T>() uses dynamic_cast which is fine in the majority of cases, but when one of them shows up in profiles, we can make it faster by answering the is-a question manually.
2021-01-17 09:34:01 +01:00
// These are used to optimize hot is<T> variants for some classes where dynamic_cast is too slow.
LibWeb: Specialize is<DOM::Element>() and is<Layout::Box>() These two show up in profiles, so let's add specializations for them.
2021-01-07 17:31:26 +01:00
virtual bool is_box() const { return false; }
LibWeb: Rename Layout::Node::is_block_box() => is_block_container()
2021-10-06 20:07:13 +02:00
virtual bool is_block_container() const { return false; }
LibWeb: Fix inline blocks swallowing trailing whitespace In #10434 an issue with leading whitespace in new lines after a <br> element was fixed by checking whether the last fragment of LineBox is empty. However, this introduced a regression by which whitespace following inline elements was swallowed, so `<b>Test</b> 123` would appear like `Test123`. By asking specifically if we are handling a forced linebreak instead of implicity asking for a property that may be shared by other Node types, we can maintain the correct behavior in regards to leading whitespace on new lines, as well as trailing whitespace of inline elements.
2021-10-26 16:15:53 +02:00
virtual bool is_break_node() const { return false; }
LibWeb: Add fast_is<T>() for some DOM and layout node subclasses The generic is<T>() uses dynamic_cast which is fine in the majority of cases, but when one of them shows up in profiles, we can make it faster by answering the is-a question manually.
2021-01-17 09:34:01 +01:00
virtual bool is_text_node() const { return false; }
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
virtual bool is_viewport() const { return false; }
LibWeb: Add fast_is<T>() for SVGBox and SVGPathBox
2021-10-18 16:26:05 +02:00
virtual bool is_svg_box() const { return false; }
LibWeb: Rename SVGPathBox -> SVGGeometryBox This fits better since it's now used by all SVGGeometryElements.
2022-02-11 12:37:22 +00:00
virtual bool is_svg_geometry_box() const { return false; }
LibWeb: Support masking of SVGForeignObjectPaintable
2024-04-25 21:10:30 +02:00
virtual bool is_svg_mask_box() const { return false; }
LibWeb: Add fast_is<T>() for various types stood out in a profile
2023-03-10 21:16:18 +01:00
virtual bool is_svg_svg_box() const { return false; }
LibWeb: Add more fast_is<T> helpers for layout and paintable nodes
2025-04-18 10:28:46 +02:00
virtual bool is_svg_graphics_box() const { return false; }
LibWeb: Make SVG foreignObject establish a new stacking context This matches the behavior of Blink and Gecko, but not WebKit.
2025-07-06 15:00:51 +02:00
virtual bool is_svg_foreign_object_box() const { return false; }
LibWeb: Add fast_is<T>() for Layout::Label Spotted this in a profile while wheel scrolling up & down.
2021-10-27 17:58:19 +02:00
virtual bool is_label() const { return false; }
LibWeb: Add some fast_is<T> helpers for hot classes on GitHub :^)
2022-03-13 17:21:27 +01:00
virtual bool is_replaced_box() const { return false; }
LibWeb: Add fast_is<T>() for various types stood out in a profile
2023-03-10 21:16:18 +01:00
virtual bool is_list_item_box() const { return false; }
LibWeb: Add some fast_is<T> helpers for hot classes on GitHub :^)
2022-03-13 17:21:27 +01:00
virtual bool is_list_item_marker_box() const { return false; }
LibWeb: Add layout objects for fieldset and legend Add the boilerplate code for the layout objects that represent the `<fieldset>` and `<legend>` elements. Using these, we can make progress towards laying out these two elements per the spec at https://html.spec.whatwg.org/multipage/rendering.html#the-fieldset-and-legend-elements.
2024-11-05 08:07:13 +00:00
virtual bool is_fieldset_box() const { return false; }
virtual bool is_legend_box() const { return false; }
LibWeb: Override width calculation for table wrappers Introduce `TableWrapper` type so table wrappers could be distinguished from block containers and override width calculation for table wrappers (CSS 2.2 spec, section 17.5.2) inside BFCs in the way that their width should be equal to width of table box they wrap.
2023-01-14 14:48:20 +01:00
virtual bool is_table_wrapper() const { return false; }
LibWeb: Add more fast_is<T> helpers for layout and paintable nodes
2025-04-18 10:28:46 +02:00
virtual bool is_node_with_style() const { return false; }
LibWeb: Add fast_is<T>() for various types stood out in a profile
2023-03-10 21:16:18 +01:00
virtual bool is_node_with_style_and_box_model_metrics() const { return false; }
LibWeb: Add fast_is<T>() for some DOM and layout node subclasses The generic is<T>() uses dynamic_cast which is fine in the majority of cases, but when one of them shows up in profiles, we can make it faster by answering the is-a question manually.
2021-01-17 09:34:01 +01:00
template<typename T>
bool fast_is() const = delete;
LibWeb: Specialize is<DOM::Element>() and is<Layout::Box>() These two show up in profiles, so let's add specializations for them.
2021-01-07 17:31:26 +01:00
LibWeb: Add the 'float' CSS property to LayoutStyle Note that we don't use the property for anything yet, as I'm still wrapping my head around how to implement floats.
2020-06-26 15:08:42 +02:00
bool is_floating() const;
LibWeb: Add Layout::Node::is_positioned() Any node that has a CSS position other than "static" is positioned.
2020-12-06 19:54:23 +01:00
bool is_positioned() const;
LibWeb: Improve computation of a layout node's containing block In particular, we now compute the containing block of boxes with position:absolute and position:fixed (more) correctly.
2020-06-05 16:54:28 +02:00
bool is_absolutely_positioned() const;
LibWeb: Add basic support for position:fixed Fixed position elements have the ICB as their containing block. The magic of fixed positioning is implemented at the rendering stage, where we temporarily translate painting by the current scroll offset. Note that "absolutely positioned" includes both position:absolute and position:fixed.
2020-06-12 14:19:03 +02:00
bool is_fixed_position() const;
LibWeb: Add "position: sticky" support Sticky positioning is implemented by modifying the algorithm for assigning and refreshing scroll frames. Now, elements with "position: sticky" are assigned their own scroll frame, and their position is refreshed independently from regular scroll boxes. Refreshing the scroll offsets for sticky boxes does not require display list invalidation. A separate hash map is used for the scroll frames of sticky boxes. This is necessary because a single paintable box can have two scroll frames if it 1) has "position: sticky" and 2) contains scrollable overflow.
2024-08-24 19:20:31 +02:00
bool is_sticky_position() const;
LibWeb: Improve computation of a layout node's containing block In particular, we now compute the containing block of boxes with position:absolute and position:fixed (more) correctly.
2020-06-05 16:54:28 +02:00
LibWeb: LayoutNodes know whether they are flex-items This is useful for debugging when dumping the layout tree.
2021-05-29 22:36:15 +02:00
bool is_flex_item() const { return m_is_flex_item; }
void set_flex_item(bool b) { m_is_flex_item = b; }
LibWeb: Add `m_is_grid_item` in `Layout::Node` This information is going to be needed during painting to treat grid items as stacking contexts.
2023-08-20 19:30:39 +02:00
bool is_grid_item() const { return m_is_grid_item; }
void set_grid_item(bool b) { m_is_grid_item = b; }
LibWeb: Compute containing block boxes once at start of layout We now cache the containing block (box) once at the start of layout, which allows Layout::Node::containing_block() to return instantly instead of doing tree traversal. Removes a 0.7% profile item on Speedometer 3.
2025-04-18 11:39:23 +02:00
[[nodiscard]] GC::Ptr<Box const> containing_block() const { return m_containing_block; }
[[nodiscard]] GC::Ptr<Box> containing_block() { return m_containing_block; }
void recompute_containing_block(Badge<DOM::Document>);
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
[[nodiscard]] Box const* static_position_containing_block() const;
[[nodiscard]] Box* static_position_containing_block() { return const_cast<Box*>(const_cast<Node const*>(this)->static_position_containing_block()); }
LibWeb: Get reference height from closest non-anonymous ancestor Ignore anonymous block boxes when resolving percentage weights that would refer to them, per the CSS 2 visual formatting model specification. This fixes the case when we create an anonymous block between an image which uses a percentage height relative to a parent which specifies a definite height. Fixes #19052.
2023-05-24 06:57:38 +00:00
// Closest non-anonymous ancestor box, to be used when resolving percentage values.
// Anonymous block boxes are ignored when resolving percentage values that would refer to it:
// the closest non-anonymous ancestor box is used instead.
// https://www.w3.org/TR/CSS22/visuren.html#anonymous-block-level
LibWeb: Fix spelling of non_anonymous_containing_block()
2023-06-14 15:31:40 +02:00
Box const* non_anonymous_containing_block() const;
LibWeb: Get reference height from closest non-anonymous ancestor Ignore anonymous block boxes when resolving percentage weights that would refer to them, per the CSS 2 visual formatting model specification. This fixes the case when we create an anonymous block between an image which uses a percentage height relative to a parent which specifies a definite height. Fixes #19052.
2023-05-24 06:57:38 +00:00
LibWeb: Make painting order more spec-compliant Now our painting order inside stacking contexts is closer to the algorithm specified by CSS 2.1 (see section 9.9 and Appendix E)
2021-05-07 19:03:25 +03:00
bool establishes_stacking_context() const;
LibWeb: Improve computation of a layout node's containing block In particular, we now compute the containing block of boxes with position:absolute and position:fixed (more) correctly.
2020-06-05 16:54:28 +02:00
bool can_contain_boxes_with_position_absolute() const;
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
Gfx::Font const& first_available_font() const;
LibWeb: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 23:07:26 +02:00
Gfx::Font const& font(DisplayListRecordingContext&) const;
LibGfx: Join ScaledFont into Font Since ScaledFont is the only class inherited from Font we could simply merge them.
2025-04-19 19:10:01 +02:00
Gfx::Font const& font(float scale_factor) const;
LibWeb: Add .scaled_font() helper to Layout::Node This returns the font scaled for the current zoom level.
2023-04-01 21:12:15 +01:00
LibWeb: Convert Layout::Node to new pixel units
2022-11-08 11:31:24 +00:00
CSS::ImmutableComputedValues const& computed_values() const;
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
NodeWithStyle* parent();
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
NodeWithStyle const* parent() const;
LibHTML: Fetch the box edge values needed for block width computation.
2019-07-24 07:34:07 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
void inserted_into(Node&) { }
void removed_from(Node&) { }
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
void children_changed() { }
LibHTML: Add inserted_into() and removed_from() TreeNode callbacks These will be called when a Node or LayoutNode is inserted or removed from a tree. They get the parent node as an argument.
2019-09-29 17:40:39 +02:00
LibHTML: Make "children are inline" flag imperative Instead of computing whether a block's children are inline based on the first child, make it an imperatively-set flag. This gives us some flexibility to ignore things like text nodes inside a <table>, for example. I'm still unsure what the "correct" way to deal with those will be. We'll find out sooner or later. :^)
2019-10-17 23:32:08 +02:00
bool children_are_inline() const { return m_children_are_inline; }
void set_children_are_inline(bool value) { m_children_are_inline = value; }
LibWeb: Track quote-nesting level while building the layout tree This makes multiple levels of quote actually use different quotation marks, instead of always the first available pair of them. Each Layout::Node remembers what the quote-nesting level was before its content was evaluated, so that we can re-use this number in `apply_style()`. This is a bit hacky, since we end up converting the `content` value into a string twice. `StyleProperties::content()` now takes an initial quote-nesting level, and returns the final level after that content.
2023-09-18 15:41:17 +01:00
u32 initial_quote_nesting_level() const { return m_initial_quote_nesting_level; }
void set_initial_quote_nesting_level(u32 value) { m_initial_quote_nesting_level = value; }
LibWeb: Refactor out-of-flow and in-flow into functions The concept of out-of-flow and in-flow elements is used in a few places in the layout code. This change refactors these concepts into functions.
2024-07-04 23:58:56 +02:00
// An element is called out of flow if it is floated, absolutely positioned, or is the root element.
// https://www.w3.org/TR/CSS22/visuren.html#positioning-scheme
bool is_out_of_flow() const { return is_floating() || is_absolutely_positioned(); }
// An element is called in-flow if it is not out-of-flow.
// https://www.w3.org/TR/CSS22/visuren.html#positioning-scheme
bool is_in_flow() const { return !is_out_of_flow(); }
LibWeb: Fix incomplete plumbing for individual `rotate` CSS property
2024-11-22 16:11:33 +01:00
[[nodiscard]] bool has_css_transform() const
{
LibWeb: Reformat `Node/PaintableBox::has_css_transform()` Slightly more visually pleasing. No functional changes.
2025-06-16 16:53:56 +02:00
auto const& computed_values = this->computed_values();
return !computed_values.transformations().is_empty()
|| computed_values.rotate().has_value()
|| computed_values.translate().has_value()
|| computed_values.scale().has_value();
LibWeb: Fix incomplete plumbing for individual `rotate` CSS property
2024-11-22 16:11:33 +01:00
}
LibWeb: Fix overflow clip when "complicated" CSS transform is used Overflow clipping is currently implemented as: 1. Create clip frame for each box with hidden overflow 2. Calculate clip rect for each clip frame by intersecting padding boxes of all boxes with hidden overflow in containing block chain 3. Assign enclosing clip frame (closest clip frame in containing block chain) to each PaintableBox 4. Apply clip rect of enclosing clip frame in Paintable::before_paint() It breaks when any CSS transform other than simple translation is lying between box with hidden overflow and a clipped box, because clip rectangle will be applied when transform has already changed. The fix is implemented by relying on the following rule: "For elements whose layout is governed by the CSS box model, any value other than none for the transform also causes the element to establish a containing block for all descendants." It means everything nested into a stacking context with CSS transform can't escape its clip, so it's safe to apply its clip for all children.
2024-07-31 22:26:43 +03:00
LibWeb: Implement user-select This implements all values of user-select.
2025-01-08 01:51:29 +01:00
// https://drafts.csswg.org/css-ui/#propdef-user-select
CSS::UserSelect user_select_used_value() const;
LibWeb: Move containment checks to Layout::Node It fits better there and avoids having to reach into the Element all the time.
2025-05-09 21:34:47 +02:00
// https://drafts.csswg.org/css-contain-2/#containment-types
bool has_size_containment() const;
bool has_inline_size_containment() const;
bool has_layout_containment() const;
bool has_style_containment() const;
bool has_paint_containment() const;
LibWeb: Don't (anonymously) wrap table boxes that are already wrapped Instead just update the existing wrapper with computed values from the table box, to insure that upside-down "inheritance" works as expected. This allows table fixup to run on partially updated layout trees without adding a new layer of unnecessary wrappers every time.
2025-01-11 20:22:24 +01:00
[[nodiscard]] bool has_been_wrapped_in_table_wrapper() const { return m_has_been_wrapped_in_table_wrapper; }
void set_has_been_wrapped_in_table_wrapper(bool value) { m_has_been_wrapped_in_table_wrapper = value; }
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
protected:
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
Node(DOM::Document&, DOM::Node*);
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
virtual void visit_edges(Cell::Visitor&) override;
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
private:
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
friend class NodeWithStyle;
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<DOM::Node> m_dom_node;
LibWeb: Allow layout nodes to have multiple paintables CSS fragmentation implies 1:N relationship between layout nodes and paintables. This change is a preparation for implementation of inline fragmentation where InlinePaintable will be replaced with PaintableWithLines corresponding to each line.
2024-10-14 16:07:56 +02:00
PaintableList m_paintable;
LibHTML: Add a simple TreeNode<T> template for making trees. We'll be making a lot of trees here, so let's share code during bootstrap. Eventually some of these classes are gonna want custom trees but for now we can just fit them all into the same clothes.
2019-06-25 19:46:01 +02:00
LibWeb: Compute containing block boxes once at start of layout We now cache the containing block (box) once at the start of layout, which allows Layout::Node::containing_block() to return instantly instead of doing tree traversal. Removes a 0.7% profile item on Speedometer 3.
2025-04-18 11:39:23 +02:00
GC::Ptr<Box> m_containing_block;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<DOM::Element> m_pseudo_element_generator;
LibWeb: Add info about pseudo element type in Layout::Node
2023-08-06 01:29:55 +02:00
LibWeb: Only store one DOM pointer per Layout::Node Instead of storing two JS::Handles into the DOM, we can combine them into a single one. If the layout node is anonymous, m_dom_node points to the DOM::Document. Otherwise, m_dom_node points to the associated DOM node. The anonymous state is moved to an m_anonymous boolean member. This cuts the number of JS::Handles created by the layout tree in half (and shrinks Layout::Node by 8 bytes).
2022-10-16 16:42:39 +02:00
bool m_anonymous { false };
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
bool m_has_style { false };
LibHTML: Make "children are inline" flag imperative Instead of computing whether a block's children are inline based on the first child, make it an imperatively-set flag. This gives us some flexibility to ignore things like text nodes inside a <table>, for example. I'm still unsure what the "correct" way to deal with those will be. We'll find out sooner or later. :^)
2019-10-17 23:32:08 +02:00
bool m_children_are_inline { false };
LibWeb: LayoutNodes know whether they are flex-items This is useful for debugging when dumping the layout tree.
2021-05-29 22:36:15 +02:00
bool m_is_flex_item { false };
LibWeb: Add `m_is_grid_item` in `Layout::Node` This information is going to be needed during painting to treat grid items as stacking contexts.
2023-08-20 19:30:39 +02:00
bool m_is_grid_item { false };
LibWeb: Don't (anonymously) wrap table boxes that are already wrapped Instead just update the existing wrapper with computed values from the table box, to insure that upside-down "inheritance" works as expected. This allows table fixup to run on partially updated layout trees without adding a new layer of unnecessary wrappers every time.
2025-01-11 20:22:24 +01:00
bool m_has_been_wrapped_in_table_wrapper { false };
LibWeb: Move "needs layout update" flag from DOM to layout tree This is in preparation for allowing anonymous boxes to retain their intrinsic size cache across layouts.
2025-04-18 20:40:14 +02:00
bool m_needs_layout_update { false };
LibWeb: Remove GeneratedPseudoElement enum This doesn't currently provide any value over just using PseudoElement, and makes it harder to work with PseudoElement in other places.
2025-06-05 17:18:12 +01:00
Optional<CSS::PseudoElement> m_generated_for {};
LibWeb: Track quote-nesting level while building the layout tree This makes multiple levels of quote actually use different quotation marks, instead of always the first available pair of them. Each Layout::Node remembers what the quote-nesting level was before its content was evaluated, so that we can re-use this number in `apply_style()`. This is a bit hacky, since we end up converting the `content` value into a string twice. `StyleProperties::content()` now takes an initial quote-nesting level, and returns the final level after that content.
2023-09-18 15:41:17 +01:00
u32 m_initial_quote_nesting_level { 0 };
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
};
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 19:35:33 -07:00
class WEB_API NodeWithStyle : public Node {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(NodeWithStyle, Node);
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
public:
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
virtual ~NodeWithStyle() override = default;
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
LibWeb: Allocate CSS::ComputedValues objects on the heap This makes them cheap to move around, since we can store them in a NonnullOwnPtr instead of memcopying 2584(!) bytes. Drastically reduces the chance of stack overflow while building the layout tree for deeply nested DOMs (since tree building was putting these things on the stack). This change also exposed a completely unnecessary ComputedValues deep copy in block layout.
2024-01-27 08:38:27 +01:00
CSS::ImmutableComputedValues const& computed_values() const { return static_cast<CSS::ImmutableComputedValues const&>(*m_computed_values); }
CSS::MutableComputedValues& mutable_computed_values() { return static_cast<CSS::MutableComputedValues&>(*m_computed_values); }
LibWeb: Add LayoutStyle, a place to store style info for layout & paint StyleProperties is really only the specified "input" to what eventually becomes the used/computed style we use for layout and painting. Unlike StyleProperties, LayoutStyle will have strongly typed values for everything it contains (i.e no CSS::ValueID or strings, etc.) This first patch moves z-index into LayoutStyle.
2020-06-24 14:17:05 +02:00
LibWeb: Support inserting non-inline elements into inline elements Our layout tree requires that all containers either have inline or non-inline children. In order to support the layout of non-inline elements inside inline elements, we need to do a bit of tree restructuring. It effectively simulates temporarily closing all inline nodes, appending the block element, and resumes appending to the last open inline node. The acid1.txt expectation needed to be updated to reflect the fact that we now hoist its <p> elements out of the inline <form> they were in. Visually, the before and after situations for acid1.html are identical.
2025-01-15 16:37:30 +01:00
void apply_style(CSS::ComputedProperties const&);
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
Gfx::Font const& first_available_font() const;
LibWeb: Store background layers in ComputedValues Instead of storing these as individual `background-foo` properties, we combine them together into layers, since that is how they will be painted. It also makes it more convenient to pass them around.
2021-11-12 12:11:01 +00:00
Vector<CSS::BackgroundLayerData> const& background_layers() const { return computed_values().background_layers(); }
LibWeb: Convert images to common AbstractImageStyleValue base This commit moves both the ImageStyleValue and LinearGradientStyleValue to a common base class of AbstractImageStyleValue. This abstracts getting the natural_width/height, loading/resolving, and painting the image. Now for 'free' you get: - Linear gradients working with the various background sizing/repeat properties. - Linear gradients working as list-markers :^) -- best feature ever! P.s. This commit is a little large as it's tricky to make this change incrementally without breaking things.
2022-07-31 01:11:59 +01:00
const CSS::AbstractImageStyleValue* list_style_image() const { return m_list_style_image; }
LibWeb: Store the used font in Layout::NodeWithStyle This is a step towards not having to carry the full set of specified values around with every layout node.
2021-01-06 11:05:23 +01:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<NodeWithStyle> create_anonymous_wrapper() const;
LibWeb: Remove specified style from layout nodes Layout nodes now only carry CSS computer values with them. The main idea here is to give them only what they need to perform layout, and leave the rest back in the DOM.
2021-01-06 14:10:53 +01:00
LibWeb: Fix style updates for table box nodes On style update, we have to preserve the invariant established when we built the layout tree - some properties are applied to the table wrapper and the table box values are reset to their initial values. This also ensures that the containing block of a table box is always a table wrapper, which isn't the case if we set absolute position on the box instead of the wrapper. Fixes #19452.
2023-06-22 12:22:29 +00:00
void transfer_table_box_computed_values_to_wrapper_computed_values(CSS::ComputedValues& wrapper_computed_values);
LibWeb: Wrap table roots in anonymous block boxes According to table fixup algorithm: https://www.w3.org/TR/css-tables-3/#fixup-algorithm around every table-root should be generated anonymous box wrapper. Also this patch implements important part of CSS 2.2 spec that is currently not present in CSS Tables 3 spec draft: https://www.w3.org/TR/CSS22/tables.html#model that portion of computed properties should be moved from table-root to table wrapper box. Without having this part implemented height of absolutely positioned table with `height: auto` won't be computed correctly.
2023-01-09 08:27:39 +03:00
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 21:29:47 +02:00
bool is_body() const;
bool is_scroll_container() const;
LibWeb: Add missing visit_edges() for ImageStyleValue ImageStyleValue has a visit_edges() method, although it is not a GC-allocated object. This is necessary because it owns a GC-allocated ImageRequest that we want to visit, instead of using JS::Handle, to avoid leaks. In the future, we might want to make StyleValue be GC-allocated. For now, this change adds missing visit_edges() calls for objects that own ImageStyleValue.
2023-09-28 00:26:02 +02:00
virtual void visit_edges(Cell::Visitor& visitor) override;
LibWeb: Don't (anonymously) wrap table boxes that are already wrapped Instead just update the existing wrapper with computed values from the table box, to insure that upside-down "inheritance" works as expected. This allows table fixup to run on partially updated layout trees without adding a new layer of unnecessary wrappers every time.
2025-01-11 20:22:24 +01:00
void set_computed_values(NonnullOwnPtr<CSS::ComputedValues>);
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
protected:
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 16:35:12 +01:00
NodeWithStyle(DOM::Document&, DOM::Node*, GC::Ref<CSS::ComputedProperties>);
LibWeb: Allocate CSS::ComputedValues objects on the heap This makes them cheap to move around, since we can store them in a NonnullOwnPtr instead of memcopying 2584(!) bytes. Drastically reduces the chance of stack overflow while building the layout tree for deeply nested DOMs (since tree building was putting these things on the stack). This change also exposed a completely unnecessary ComputedValues deep copy in block layout.
2024-01-27 08:38:27 +01:00
NodeWithStyle(DOM::Document&, DOM::Node*, NonnullOwnPtr<CSS::ComputedValues>);
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
private:
LibWeb: Add more fast_is<T> helpers for layout and paintable nodes
2025-04-18 10:28:46 +02:00
virtual bool is_node_with_style() const final { return true; }
LibWeb: Fix style updates for table box nodes On style update, we have to preserve the invariant established when we built the layout tree - some properties are applied to the table wrapper and the table box values are reset to their initial values. This also ensures that the containing block of a table box is always a table wrapper, which isn't the case if we set absolute position on the box instead of the wrapper. Fixes #19452.
2023-06-22 12:22:29 +00:00
void reset_table_box_computed_values_used_by_wrapper_to_init_values();
LibWeb: Improve style propagation to anonymous wrappers - We now propagate changes in font and line-height to anonymous wrappers when doing a partial style update after invalidation. - We no longer (incorrectly) propagate style from table wrapper boxes to the table root, since inheritance works in the other direction. Fixes #22395
2024-01-07 13:05:20 +01:00
void propagate_style_to_anonymous_wrappers();
LibWeb: Fix style updates for table box nodes On style update, we have to preserve the invariant established when we built the layout tree - some properties are applied to the table wrapper and the table box values are reset to their initial values. This also ensures that the containing block of a table box is always a table wrapper, which isn't the case if we set absolute position on the box instead of the wrapper. Fixes #19452.
2023-06-22 12:22:29 +00:00
LibWeb: Allocate CSS::ComputedValues objects on the heap This makes them cheap to move around, since we can store them in a NonnullOwnPtr instead of memcopying 2584(!) bytes. Drastically reduces the chance of stack overflow while building the layout tree for deeply nested DOMs (since tree building was putting these things on the stack). This change also exposed a completely unnecessary ComputedValues deep copy in block layout.
2024-01-27 08:38:27 +01:00
NonnullOwnPtr<CSS::ComputedValues> m_computed_values;
LibWeb+LibIDL: Fix (or paper over) various const-correctness issues There's definitely stuff to iterate on here, but this takes care of making the libraries compile with stricter RP and NNRP.
2023-02-20 18:56:08 +01:00
RefPtr<CSS::AbstractImageStyleValue const> m_list_style_image;
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
};
LibWeb: Add more fast_is<T> helpers for layout and paintable nodes
2025-04-18 10:28:46 +02:00
template<>
inline bool Node::fast_is<NodeWithStyle>() const { return is_node_with_style(); }
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
class NodeWithStyleAndBoxModelMetrics : public NodeWithStyle {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(NodeWithStyleAndBoxModelMetrics, NodeWithStyle);
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
public:
LibWeb: Support inserting non-inline elements into inline elements Our layout tree requires that all containers either have inline or non-inline children. In order to support the layout of non-inline elements inside inline elements, we need to do a bit of tree restructuring. It effectively simulates temporarily closing all inline nodes, appending the block element, and resumes appending to the last open inline node. The acid1.txt expectation needed to be updated to reflect the fact that we now hoist its <p> elements out of the inline <form> they were in. Visually, the before and after situations for acid1.html are identical.
2025-01-15 16:37:30 +01:00
GC::Ptr<NodeWithStyleAndBoxModelMetrics> continuation_of_node() const { return m_continuation_of_node; }
void set_continuation_of_node(Badge<TreeBuilder>, GC::Ptr<NodeWithStyleAndBoxModelMetrics> node) { m_continuation_of_node = node; }
LibWeb: Factor out conditions for creation of inline continuation Having one big `if` to determine whether or not we should restructure an inline layout node became a bit unwieldy. This extracts the logic into a separate method.
2025-02-19 10:54:44 +01:00
bool should_create_inline_continuation() const;
LibWeb: Support inserting non-inline elements into inline elements Our layout tree requires that all containers either have inline or non-inline children. In order to support the layout of non-inline elements inside inline elements, we need to do a bit of tree restructuring. It effectively simulates temporarily closing all inline nodes, appending the block element, and resumes appending to the last open inline node. The acid1.txt expectation needed to be updated to reflect the fact that we now hoist its <p> elements out of the inline <form> they were in. Visually, the before and after situations for acid1.html are identical.
2025-01-15 16:37:30 +01:00
void propagate_style_along_continuation(CSS::ComputedProperties const&) const;
virtual void visit_edges(Cell::Visitor& visitor) override;
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
protected:
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 16:35:12 +01:00
NodeWithStyleAndBoxModelMetrics(DOM::Document& document, DOM::Node* node, GC::Ref<CSS::ComputedProperties> style)
: NodeWithStyle(document, node, style)
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
{
}
LibWeb: Allocate CSS::ComputedValues objects on the heap This makes them cheap to move around, since we can store them in a NonnullOwnPtr instead of memcopying 2584(!) bytes. Drastically reduces the chance of stack overflow while building the layout tree for deeply nested DOMs (since tree building was putting these things on the stack). This change also exposed a completely unnecessary ComputedValues deep copy in block layout.
2024-01-27 08:38:27 +01:00
NodeWithStyleAndBoxModelMetrics(DOM::Document& document, DOM::Node* node, NonnullOwnPtr<CSS::ComputedValues> computed_values)
LibWeb: Remove specified style from layout nodes Layout nodes now only carry CSS computer values with them. The main idea here is to give them only what they need to perform layout, and leave the rest back in the DOM.
2021-01-06 14:10:53 +01:00
: NodeWithStyle(document, node, move(computed_values))
{
}
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
private:
LibWeb: Add fast_is<T>() for various types stood out in a profile
2023-03-10 21:16:18 +01:00
virtual bool is_node_with_style_and_box_model_metrics() const final { return true; }
LibWeb: Support inserting non-inline elements into inline elements Our layout tree requires that all containers either have inline or non-inline children. In order to support the layout of non-inline elements inside inline elements, we need to do a bit of tree restructuring. It effectively simulates temporarily closing all inline nodes, appending the block element, and resumes appending to the last open inline node. The acid1.txt expectation needed to be updated to reflect the fact that we now hoist its <p> elements out of the inline <form> they were in. Visually, the before and after situations for acid1.html are identical.
2025-01-15 16:37:30 +01:00
GC::Ptr<NodeWithStyleAndBoxModelMetrics> m_continuation_of_node;
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
};
LibWeb: Add fast_is<T>() for various types stood out in a profile
2023-03-10 21:16:18 +01:00
template<>
inline bool Node::fast_is<NodeWithStyleAndBoxModelMetrics>() const { return is_node_with_style_and_box_model_metrics(); }
LibWeb: Verify that a node has styled properties in its styled accessors For example, it's possible to access Node::computed_values() on a node that neither has style nor a parent with style. This ultimately results in a null pointer dereference when we return parent()->computed_values() as a fallback. This can be a little tricky to track down due to these functions being inlined, so add an explicit verification.
2023-04-27 09:03:49 -04:00
inline bool Node::has_style_or_parent_with_style() const
{
return m_has_style || (parent() != nullptr && parent()->has_style_or_parent_with_style());
}
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
inline Gfx::Font const& Node::first_available_font() const
LibWeb: Store the used font in Layout::NodeWithStyle This is a step towards not having to carry the full set of specified values around with every layout node.
2021-01-06 11:05:23 +01:00
{
LibWeb: Verify that a node has styled properties in its styled accessors For example, it's possible to access Node::computed_values() on a node that neither has style nor a parent with style. This ultimately results in a null pointer dereference when we return parent()->computed_values() as a fallback. This can be a little tricky to track down due to these functions being inlined, so add an explicit verification.
2023-04-27 09:03:49 -04:00
VERIFY(has_style_or_parent_with_style());
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
if (m_has_style)
return static_cast<NodeWithStyle const*>(this)->first_available_font();
return parent()->first_available_font();
}
LibWeb: Verify that a node has styled properties in its styled accessors For example, it's possible to access Node::computed_values() on a node that neither has style nor a parent with style. This ultimately results in a null pointer dereference when we return parent()->computed_values() as a fallback. This can be a little tricky to track down due to these functions being inlined, so add an explicit verification.
2023-04-27 09:03:49 -04:00
LibWeb: Rename PaintContext to DisplayListRecordingContext PaintContext dates back to a time when display lists didn't exist and it truly represented "paint context". Renaming it to better align with its current role.
2025-07-31 23:07:26 +02:00
inline Gfx::Font const& Node::font(DisplayListRecordingContext& context) const
LibWeb: Add .scaled_font() helper to Layout::Node This returns the font scaled for the current zoom level.
2023-04-01 21:12:15 +01:00
{
LibGfx: Join ScaledFont into Font Since ScaledFont is the only class inherited from Font we could simply merge them.
2025-04-19 19:10:01 +02:00
return font(context.device_pixels_per_css_pixel());
LibWeb: Add Node::scaled_font(float scale_factor) This will allow fetching fonts scaled by a transform.
2023-07-20 20:24:22 +01:00
}
LibGfx: Join ScaledFont into Font Since ScaledFont is the only class inherited from Font we could simply merge them.
2025-04-19 19:10:01 +02:00
inline Gfx::Font const& Node::font(float scale_factor) const
LibWeb: Add Node::scaled_font(float scale_factor) This will allow fetching fonts scaled by a transform.
2023-07-20 20:24:22 +01:00
{
LibGfx+LibWeb: Move Gfx::ScaledFont caching from LibWeb into LibGfx Before this change, we would only cache and reuse Gfx::ScaledFont instances for downloaded CSS fonts. By moving it into Gfx::VectorFont, we get caching for all vector fonts, including local system TTFs etc. This avoids a *lot* of style invalidations in LibWeb, since we now vend the same Gfx::Font pointer for the same font when used repeatedly.
2023-12-25 12:45:18 +01:00
auto const& font = first_available_font();
LibGfx+LibWeb: Allow inexact size lookups when requesting scaled fonts For bitmap fonts, we will often not have an exact match for requested sizes. Return the closest match instead of a nullptr. LibWeb is currently the only user of this API. If it needs to be configurable in the future to only allow exact matches, we can add a parameter or another method at that time.
2024-05-06 13:12:16 -04:00
return font.with_size(font.point_size() * scale_factor);
LibWeb: Add .scaled_font() helper to Layout::Node This returns the font scaled for the current zoom level.
2023-04-01 21:12:15 +01:00
}
LibWeb: Rename Layout::Node::style() => computed_values()
2021-01-06 11:07:02 +01:00
inline const CSS::ImmutableComputedValues& Node::computed_values() const
LibWeb: Add LayoutStyle, a place to store style info for layout & paint StyleProperties is really only the specified "input" to what eventually becomes the used/computed style we use for layout and painting. Unlike StyleProperties, LayoutStyle will have strongly typed values for everything it contains (i.e no CSS::ValueID or strings, etc.) This first patch moves z-index into LayoutStyle.
2020-06-24 14:17:05 +02:00
{
LibWeb: Verify that a node has styled properties in its styled accessors For example, it's possible to access Node::computed_values() on a node that neither has style nor a parent with style. This ultimately results in a null pointer dereference when we return parent()->computed_values() as a fallback. This can be a little tricky to track down due to these functions being inlined, so add an explicit verification.
2023-04-27 09:03:49 -04:00
VERIFY(has_style_or_parent_with_style());
LibWeb: Add LayoutStyle, a place to store style info for layout & paint StyleProperties is really only the specified "input" to what eventually becomes the used/computed style we use for layout and painting. Unlike StyleProperties, LayoutStyle will have strongly typed values for everything it contains (i.e no CSS::ValueID or strings, etc.) This first patch moves z-index into LayoutStyle.
2020-06-24 14:17:05 +02:00
if (m_has_style)
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
return static_cast<NodeWithStyle const*>(this)->computed_values();
LibWeb: Rename LayoutStyle => CSS::ComputedValues This object represents the CSS "computed values" so let's call it that.
2021-01-06 10:34:31 +01:00
return parent()->computed_values();
LibWeb: Add LayoutStyle, a place to store style info for layout & paint StyleProperties is really only the specified "input" to what eventually becomes the used/computed style we use for layout and painting. Unlike StyleProperties, LayoutStyle will have strongly typed values for everything it contains (i.e no CSS::ValueID or strings, etc.) This first patch moves z-index into LayoutStyle.
2020-06-24 14:17:05 +02:00
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
inline NodeWithStyle const* Node::parent() const
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
{
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
return static_cast<NodeWithStyle const*>(TreeNode<Node>::parent());
LibHTML: Add LayoutNodeWithStyle class, make LayoutText style-less Since LayoutText always inherits style, it shouldn't store any style of its own. This patch adds a LayoutNodeWithStyle class to sit between LayoutNode and everyone who wants to inherit from LayoutNode except LayoutText :^) Since LayoutText can never have children, we also know that the parent of any LayoutNode is always going to be a LayoutNodeWithStyle. So this patch makes LayoutNode::parent() return LayoutNodeWithStyle*.
2019-10-07 09:50:31 +02:00
}
LibHTML: Add is<T> and to<T> helpers for LayoutNode class family
2019-10-15 14:19:52 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
inline NodeWithStyle* Node::parent()
LibHTML: Add LayoutNode::first_ancestor_of_type<T>()
2019-10-18 10:16:33 +02:00
{
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
return static_cast<NodeWithStyle*>(TreeNode<Node>::parent());
LibHTML: Add LayoutNode::first_ancestor_of_type<T>()
2019-10-18 10:16:33 +02:00
}
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
inline Gfx::Font const& NodeWithStyle::first_available_font() const
{
// https://drafts.csswg.org/css-fonts/#first-available-font
LibWeb: Find font that has whitespace glyph in first_available_font() Fixes https://github.com/SerenityOS/serenity/issues/22853
2024-01-21 22:53:54 +01:00
// First font for which the character U+0020 (space) is not excluded by a unicode-range
return computed_values().font_list().font_for_code_point(' ');
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
}
LibWeb: Add some iteration helpers to LayoutNode - for_each_child_of_type<T> - previous_sibling_of_type<T>
2020-06-09 20:42:11 +02:00
}
Reference in a new issue Copy permalink