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

221 lines
9.8 KiB
C
Raw Normal View History

LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <AK/HashMap.h>
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
#include <LibGfx/Path.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <LibGfx/Point.h>
LibWeb: Store overflow data in the FormattingState
2022-02-21 11:22:08 +01:00
#include <LibWeb/Layout/Box.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
#include <LibWeb/Layout/LineBox.h>
LibWeb: Move PaintingBox to its own .cpp and .h files
2022-03-10 23:13:37 +01:00
#include <LibWeb/Painting/PaintableBox.h>
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
#include <LibWeb/Painting/SVGGraphicsPaintable.h>
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
namespace Web::Layout {
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
enum class SizeConstraint {
None,
MinContent,
MaxContent,
};
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
class AvailableSize;
class AvailableSpace;
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
// https://www.w3.org/TR/css-position-3/#static-position-rectangle
struct StaticPositionRect {
enum class Alignment {
Start,
Center,
End,
};
CSSPixelRect rect;
Alignment horizontal_alignment { Alignment::Start };
Alignment vertical_alignment { Alignment::Start };
CSSPixelPoint aligned_position_for_box_with_size(CSSPixelSize const& size) const
{
CSSPixelPoint position = rect.location();
if (horizontal_alignment == Alignment::Center)
position.set_x(position.x() + (rect.width() - size.width()) / 2);
else if (horizontal_alignment == Alignment::End)
position.set_x(position.x() + rect.width() - size.width());
if (vertical_alignment == Alignment::Center)
position.set_y(position.y() + (rect.height() - size.height()) / 2);
else if (vertical_alignment == Alignment::End)
position.set_y(position.y() + rect.height() - size.height());
return position;
}
};
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
struct LayoutState {
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
struct UsedValues {
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
NodeWithStyle const& node() const { return *m_node; }
LibWeb: Assign sticky insets to Layout::InlineNode Before this change we were ignoring boxes with `display: inline` while assigning sticky insets. This was not correct because inline boxes are allowed to have sticky positioning. Fixes: https://github.com/LadybirdBrowser/ladybird/issues/3718 https://github.com/LadybirdBrowser/ladybird/issues/3507 https://github.com/LadybirdBrowser/ladybird/issues/3133
2025-02-27 16:56:43 +01:00
NodeWithStyle& node() { return const_cast<NodeWithStyle&>(*m_node); }
LibWeb: Make node argument to UsedValues::set_node() const No functional changes.
2025-08-27 12:37:26 +02:00
void set_node(NodeWithStyle const&, UsedValues const* containing_block_used_values);
LibWeb: Stop putting the FormattingState nodes in a slow hash map Instead, put them in a Vector<OwnPtr<NodeState>>. Each layout node has a unique index into the vector. It's a simple serial ID assigned during layout tree construction. Every new layout restarts the sequence at 0 for the next ICB. This is a huge layout speed improvement on all content.
2022-07-11 17:12:58 +02:00
LibWeb: Give UsedValues a pointer to containing block UsedValues This will allow us to skip hash lookups when traversing the containing block chain and looking at everyone's UsedValues.
2024-01-17 11:23:33 +01:00
UsedValues const* containing_block_used_values() const { return m_containing_block_used_values; }
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels content_width() const { return m_content_width; }
CSSPixels content_height() const { return m_content_height; }
void set_content_width(CSSPixels);
void set_content_height(CSSPixels);
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
LibWeb: Only apply box offset if the box is not already the ancestor When determining the content/margin box rects within their ancestor's coordinate space, we were returning early if the passed in values already belonged to the requested ancestor. Unfortunately, we had already applied the used values' offset to the rect, which is the offset to the ancestor's ancestor. This simplifies the logic to always apply the rect offset after checking if we've reached the ancestor. Fixes determining float intrusions inside block elements with `margin: auto` set. Fixes #4083.
2025-04-04 11:28:03 +02:00
CSSPixelSize content_size() const { return { content_width(), content_height() }; }
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
void set_indefinite_content_width();
void set_indefinite_content_height();
LibWeb: Add UsedValues::set_has_definite_width/height() These will be used to explicitly mark some box geometry as definite at various stages of layout. It's gonna get finicky.
2024-01-29 15:35:02 +01:00
void set_has_definite_width(bool has_definite_width) { m_has_definite_width = has_definite_width; }
void set_has_definite_height(bool has_definite_height) { m_has_definite_height = has_definite_height; }
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
bool has_definite_width() const { return m_has_definite_width && width_constraint == SizeConstraint::None; }
bool has_definite_height() const { return m_has_definite_height && height_constraint == SizeConstraint::None; }
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
// Returns the available space for content inside this layout box.
// If the space in an axis is indefinite, and the outer space is an intrinsic sizing constraint,
// the constraint is used in that axis instead.
AvailableSpace available_inner_space_or_constraints_from(AvailableSpace const& outer_space) const;
LibWeb: Move LayoutState::set_content_* methods inline I see no good reason to keep them out of line, and having the methods named differently than the property they're updating caused me some confusion initially.
2025-01-27 12:07:30 +01:00
void set_content_offset(CSSPixelPoint new_offset) { offset = new_offset; }
void set_content_x(CSSPixels x) { offset.set_x(x); }
void set_content_y(CSSPixels y) { offset.set_y(y); }
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Correctly calculate static position rect when absolutely positioned element is a descendant of inline-block Sets inline block offsets in InlineFormattingContext.cpp, but this is not enough. When static position rect is calculated during layout, not all ancestors of abspos box may have their offsets calculated yet (more info here: https://github.com/LadybirdBrowser/ladybird/pull/2583#issuecomment-2507140272). So now static position rect is calculated relative to static containing block during layout and calculation relative to actual containing block is done later in FormattingContext::layout_absolutely_positioned_element. Fixes wpt/css/CSS2/abspos/static-inside-inline-block.html
2025-03-06 18:10:38 +05:00
// offset from top-left corner of content area of box's containing block to top-left corner of box's content area
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelPoint offset;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
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
SizeConstraint width_constraint { SizeConstraint::None };
SizeConstraint height_constraint { SizeConstraint::None };
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels margin_left { 0 };
CSSPixels margin_right { 0 };
CSSPixels margin_top { 0 };
CSSPixels margin_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels border_left { 0 };
CSSPixels border_right { 0 };
CSSPixels border_top { 0 };
CSSPixels border_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels padding_left { 0 };
CSSPixels padding_right { 0 };
CSSPixels padding_top { 0 };
CSSPixels padding_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels inset_left { 0 };
CSSPixels inset_right { 0 };
CSSPixels inset_top { 0 };
CSSPixels inset_bottom { 0 };
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
Vector<LineBox> line_boxes;
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
CSSPixels margin_box_left() const { return margin_left + border_left_collapsed() + padding_left; }
CSSPixels margin_box_right() const { return margin_right + border_right_collapsed() + padding_right; }
CSSPixels margin_box_top() const { return margin_top + border_top_collapsed() + padding_top; }
CSSPixels margin_box_bottom() const { return margin_bottom + border_bottom_collapsed() + padding_bottom; }
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels margin_box_width() const { return margin_box_left() + content_width() + margin_box_right(); }
CSSPixels margin_box_height() const { return margin_box_top() + content_height() + margin_box_bottom(); }
LibWeb: Add margin box helpers to Layout::FormattingState
2022-03-24 18:06:45 +01:00
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
CSSPixels border_box_left() const { return border_left_collapsed() + padding_left; }
CSSPixels border_box_right() const { return border_right_collapsed() + padding_right; }
CSSPixels border_box_top() const { return border_top_collapsed() + padding_top; }
CSSPixels border_box_bottom() const { return border_bottom_collapsed() + padding_bottom; }
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels border_box_width() const { return border_box_left() + content_width() + border_box_right(); }
CSSPixels border_box_height() const { return border_box_top() + content_height() + border_box_bottom(); }
LibWeb: Store overflow data in the FormattingState
2022-02-21 11:22:08 +01:00
LibWeb: Store box's containing line box fragment in FormattingState Layout should not change any properties of a box until the moment a FormattingState is committed.
2022-02-28 12:41:23 +01:00
Optional<LineBoxFragmentCoordinate> containing_line_box_fragment;
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
LibWeb: Include all floating descendants in BFC root's automatic height Before this change, we were only considering floating boxes that were immediate children of the BFC root.
2022-09-09 23:56:55 +02:00
void add_floating_descendant(Box const& box) { m_floating_descendants.set(&box); }
auto const& floating_descendants() const { return m_floating_descendants; }
LibWeb: Complete table border conflict resolution Add the element type and grid position to the algorithm and change the table borders painting to apply the new criteria to corners as well.
2023-07-12 04:20:37 +00:00
void set_override_borders_data(Painting::PaintableBox::BordersDataWithElementKind const& override_borders_data) { m_override_borders_data = override_borders_data; }
LibWeb: Add partial implementation of border conflict resolution Fix handling of border style specified per column as well.
2023-06-04 14:21:20 +00:00
auto const& override_borders_data() const { return m_override_borders_data; }
LibWeb: Store table cell indices and spans in PaintableBox The adjacency information is required to position borders correctly between columns and rows.
2023-07-01 02:58:11 +00:00
void set_table_cell_coordinates(Painting::PaintableBox::TableCellCoordinates const& table_cell_coordinates) { m_table_cell_coordinates = table_cell_coordinates; }
auto const& table_cell_coordinates() const { return m_table_cell_coordinates; }
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
void set_computed_svg_path(Gfx::Path const& svg_path) { m_computed_svg_path = svg_path; }
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
auto& computed_svg_path() { return m_computed_svg_path; }
void set_computed_svg_transforms(Painting::SVGGraphicsPaintable::ComputedTransforms const& computed_transforms) { m_computed_svg_transforms = computed_transforms; }
auto const& computed_svg_transforms() const { return m_computed_svg_transforms; }
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
void set_grid_template_columns(RefPtr<CSS::GridTrackSizeListStyleValue const> used_values_for_grid_template_columns) { m_grid_template_columns = move(used_values_for_grid_template_columns); }
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
auto const& grid_template_columns() const { return m_grid_template_columns; }
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
void set_grid_template_rows(RefPtr<CSS::GridTrackSizeListStyleValue const> used_values_for_grid_template_rows) { m_grid_template_rows = move(used_values_for_grid_template_rows); }
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
auto const& grid_template_rows() const { return m_grid_template_rows; }
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
void set_static_position_rect(StaticPositionRect const& static_position_rect) { m_static_position_rect = static_position_rect; }
CSSPixelPoint static_position() const
{
LibWeb: Support CSS content property images (and lists, too!) This patch expands our generated content support beyond single strings to lists of strings and/or images. Pseudo-elements like ::before and ::after can now use content:url(...) to insert anonymous image boxes into the layout tree. This is heavily used in Google Docs for UI elements.
2025-07-27 15:55:16 +02:00
if (!m_static_position_rect.has_value())
return {};
LibWeb: Simplify UsedValues::static_position() No functional changes.
2025-08-28 00:02:22 +02:00
return m_static_position_rect->aligned_position_for_box_with_size({ margin_box_width(), margin_box_height() });
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
}
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
private:
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
AvailableSize available_width_inside() const;
AvailableSize available_height_inside() const;
LibWeb: Adjust border widths for tables using collapsing borders When using the collapsing border model, cells on either side of the edge get half the specified width of the border for their box model.
2023-07-07 05:31:54 +00:00
bool use_collapsing_borders_model() const { return m_override_borders_data.has_value(); }
// Implement the collapsing border model https://www.w3.org/TR/CSS22/tables.html#collapsing-borders.
CSSPixels border_left_collapsed() const { return use_collapsing_borders_model() ? round(border_left / 2) : border_left; }
CSSPixels border_right_collapsed() const { return use_collapsing_borders_model() ? round(border_right / 2) : border_right; }
CSSPixels border_top_collapsed() const { return use_collapsing_borders_model() ? round(border_top / 2) : border_top; }
CSSPixels border_bottom_collapsed() const { return use_collapsing_borders_model() ? round(border_bottom / 2) : border_bottom; }
LibWeb: Make LayoutState::UsedValues::m_node a const pointer No mutations should ever be made to the layout node through this pointer (and none were).
2025-02-11 13:18:11 +01:00
GC::Ptr<Layout::NodeWithStyle const> m_node { nullptr };
LibWeb: Give UsedValues a pointer to containing block UsedValues This will allow us to skip hash lookups when traversing the containing block chain and looking at everyone's UsedValues.
2024-01-17 11:23:33 +01:00
UsedValues const* m_containing_block_used_values { nullptr };
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels m_content_width { 0 };
CSSPixels m_content_height { 0 };
LibWeb: Move "has-definite-width/height" flags to UsedValues This state is less static than we originally assumed, and there are special formatting context-specific rules that say certain sizes are definite in special circumstances. To be able to support this, we move the has-definite-size flags from the layout node to the UsedValues struct instead.
2022-07-17 18:46:38 +02:00
bool m_has_definite_width { false };
bool m_has_definite_height { false };
LibWeb: Include all floating descendants in BFC root's automatic height Before this change, we were only considering floating boxes that were immediate children of the BFC root.
2022-09-09 23:56:55 +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
HashTable<GC::Ptr<Box const>> m_floating_descendants;
LibWeb: Add partial implementation of border conflict resolution Fix handling of border style specified per column as well.
2023-06-04 14:21:20 +00:00
LibWeb: Complete table border conflict resolution Add the element type and grid position to the algorithm and change the table borders painting to apply the new criteria to corners as well.
2023-07-12 04:20:37 +00:00
Optional<Painting::PaintableBox::BordersDataWithElementKind> m_override_borders_data;
LibWeb: Store table cell indices and spans in PaintableBox The adjacency information is required to position borders correctly between columns and rows.
2023-07-01 02:58:11 +00:00
Optional<Painting::PaintableBox::TableCellCoordinates> m_table_cell_coordinates;
LibWeb: Store computed SVG path data/transforms in LayoutState This removes the awkward hack to recompute the layout transform at paint time, and makes it possible for path sizes to be computed during layout. For example, it's possible to use relative units in SVG shapes (e.g. <rect>), which can be resolved during layout, but would be hard to resolve again during painting.
2023-10-29 17:08:35 +00:00
LibWeb: Port painting to use the new Skia-backed Gfx::Path SVG and and CSS border rendering now sits on top of SkPath instead of the old Gfx::DeprecatedPath. Due to an imperceptible (255, 255, 255) vs (255, 254, 255) color diff in one ref test, I changed that test to not depend on border rendering for a positive result, since that was incidental.
2024-08-09 14:00:10 +02:00
Optional<Gfx::Path> m_computed_svg_path;
LibWeb: Layout SVG <text> elements during layout (not while painting) Previously, all SVG <text> elements were zero-sized boxes, that were only actually positioned and sized during painting. This led to a number of problems, the most visible of which being that text could not be scaled based on the viewBox. Which this patch, <text> elements get a correctly sized layout box, that can be hit-tested and respects the SVG viewBox. To share code with SVGGeometryElement's the PathData (from the prior commit) has been split into a computed path and computed transforms. The computed path is specific to geometry elements, but the computed transforms are shared between all SVG graphics elements.
2023-10-29 19:11:46 +00:00
Optional<Painting::SVGGraphicsPaintable::ComputedTransforms> m_computed_svg_transforms;
LibWeb: Return used values for grid tracks in getComputedStyle() That's awkward, but getComputedStyle needs to return used track values for gridTemplateColumns and gridTemplateRows properties. This change implements it by saving style values with used values into layout state, so it could be assigned to paintables during LayoutState::commit() and later accessed by style_value_for_property(). I haven't seen it used in the wild, but WPT grid tests extensively use it. For example this change helps to go from 0/10 to 8/10 on this test: https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
2024-09-09 12:15:49 +02:00
LibWeb: Make storage of CSS::StyleValues const-correct Now we consistently use `RefPtr<StyleValue const>` for all StyleValues.
2025-04-15 15:18:27 -06:00
RefPtr<CSS::GridTrackSizeListStyleValue const> m_grid_template_columns;
RefPtr<CSS::GridTrackSizeListStyleValue const> m_grid_template_rows;
LibWeb: Make FC of containing block responsible for abspos layout Before this change, a formatting context was responsible for layout of absolutely positioned boxes whose FC root box was their parent (either directly or indirectly). This only worked correctly when the containing block of the absolutely positioned child did not escape the FC root. This is because the width and height of an absolutely positioned box are resolved based on the size of its containing block, so we needed to ensure that the containing block's layout was completed before laying out an absolutely positioned box. With this change, the layout of absolutely positioned boxes is delayed until the FC responsible for the containing block's layout is complete. This has affected the way we calculate the static position. It is no longer possible to ask the FC for a box's static position, as this FC's state might be gone by the time the layout for absolutely positioned elements occurs. Instead, the "static position rectangle" (a concept from the spec) is saved in the layout state, along with information on how to align the box within this rectangle when its width and height are resolved.
2024-09-10 19:02:03 +02:00
Optional<StaticPositionRect> m_static_position_rect;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
};
LibWeb: Delete parent state pointer in LayoutState It's safe to remove this pointer because intrinsic layout should never look up a box's state beyond its containing block. This change affects the expectations of two layout tests, but both already differ slightly from other browsers, and the difference between expectations is less than 5px.
2025-03-14 01:44:02 +01:00
~LayoutState();
LibWeb: Make the paint tree a proper standalone tree Until now, paint trees have been piggybacking on the layout tree for traversal, and paintables didn't actually have their own parent/child pointers. This patch changes that by making Paintable inherit from TreeNode, and adding a new pass to LayoutState::commit() where we recursively build the new paint tree.
2023-08-18 12:30:27 +02:00
// Commits the used values produced by layout and builds a paintable tree.
void commit(Box& root);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Relax restrictions on LayoutState::get() input type Instead of only letting NodeWithStyleAndBoxModelMetrics (and subclasses) have used values in the layout state, we now allow any NodeWithStyle.
2023-09-04 12:24:48 +02:00
UsedValues& get_mutable(NodeWithStyle const&);
UsedValues const& get(NodeWithStyle const&) const;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Maintain tree order inside LayoutState Before this change, we were at the mercy of hashed pointer addresses when processing fragment relocation in LayoutState::commit(). This made inline fragment order non-deterministic, causing layouts to shift around seemingly randomly on page reload. By simply using OrderedHashMap, we automatically get tree order processing here. This fixes a bunch of flaky tests on WPT.
2025-05-19 13:18:10 +02:00
OrderedHashMap<GC::Ref<Layout::Node const>, NonnullOwnPtr<UsedValues>> used_values_per_layout_node;
LibWeb: Add functions for calculating intrinsic sizes of a Layout::Box FormattingContext can now calculate the intrinsic sizes (min-content and max-content in both axes) for a given Layout::Box. This is a rather expensive operation, as it necessitates performing two throwaway layouts of the subtree rooted at the box. Fortunately, we can cache the results of these calculations, as intrinsic sizes don't change based on other context around the box. They are intrinsic after all. :^)
2022-03-12 14:36:59 +01:00
LibWeb: Resolve relative offsets *once* after layout Instead of applying relative offsets (like position:relative insets) during painting and hit testing, we now do a pass at the end of layout and assign the final resolved offsets to paintables. This makes painting and hit testing easier since they don't have to think about relative offsets, and it also fixes a bug where offsets were not applied to text fragments inside inline-flow elements that were themselves position:relative.
2023-08-15 15:11:10 +02:00
private:
LibWeb: Resolve relpos fragment offsets only for inline paintables Prior to this change, we iterated through all fragments within each PaintableWithLines to resolve the relative position offset. This happened before transferring the fragments to their corresponding inline paintables. With this change, we significantly reduce amount of work by attempting to resolve relative position offsets only for those contained within inline paintables. Performance improvement on https://html.spec.whatwg.org/
2024-01-18 14:03:30 +01:00
void resolve_relative_positions();
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
};
LibWeb: Clamp layout content sizes to a max value instead of crashing We've historically asserted that no "saturated" size values end up as final metrics for boxes in layout. This always had a chance of producing false positives, since you can trivially create extremely large boxes with CSS. The reason we had those assertions was to catch bugs in our own engine code where we'd incorrectly end up with non-finite values in layout algorithms. At this point, we've found and fixed all known bugs of that nature, and what remains are a bunch of false positives on pages that create very large scrollable areas, iframes etc. So, let's change it! We now clamp content width and height of boxes to 17895700 pixels, apparently the same cap as Firefox uses. There's also the issue of calc() being able to produce non-finite values. Note that we don't clamp the result of calc() directly, but instead just clamp values when assigning them to content sizes. Fixes #645. Fixes #1236. Fixes #1249. Fixes #1908. Fixes #3057.
2025-02-05 14:13:33 +01:00
inline CSSPixels clamp_to_max_dimension_value(CSSPixels value)
{
if (value.might_be_saturated())
return CSSPixels(CSSPixels::max_dimension_value);
return value;
}
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
}
Reference in a new issue Copy permalink