Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Layout/LayoutState.cpp

420 lines
18 KiB
C++
Raw Normal View History

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
/*
* Copyright (c) 2022, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
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
#include <LibWeb/Layout/AvailableSpace.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/BlockContainer.h>
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
#include <LibWeb/Layout/LayoutState.h>
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
#include <LibWeb/Layout/TextNode.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
namespace Web::Layout {
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
LayoutState::UsedValues& LayoutState::get_mutable(NodeWithStyleAndBoxModelMetrics const& box)
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
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
auto serial_id = box.serial_id();
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
if (used_values_per_layout_node[serial_id])
return *used_values_per_layout_node[serial_id];
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
for (auto const* ancestor = m_parent; ancestor; ancestor = ancestor->m_parent) {
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
if (ancestor->used_values_per_layout_node[serial_id]) {
auto cow_used_values = adopt_own(*new UsedValues(*ancestor->used_values_per_layout_node[serial_id]));
auto* cow_used_values_ptr = cow_used_values.ptr();
used_values_per_layout_node[serial_id] = move(cow_used_values);
return *cow_used_values_ptr;
LibWeb: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01:00
}
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: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01: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
auto const* containing_block_used_values = box.is_viewport() ? nullptr : &get(*box.containing_block());
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: 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
used_values_per_layout_node[serial_id] = adopt_own(*new UsedValues);
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
used_values_per_layout_node[serial_id]->set_node(const_cast<NodeWithStyleAndBoxModelMetrics&>(box), containing_block_used_values);
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
return *used_values_per_layout_node[serial_id];
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
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
LayoutState::UsedValues const& LayoutState::get(NodeWithStyleAndBoxModelMetrics const& box) const
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
{
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
auto serial_id = box.serial_id();
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
if (used_values_per_layout_node[serial_id])
return *used_values_per_layout_node[serial_id];
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
for (auto* ancestor = m_parent; ancestor; ancestor = ancestor->m_parent) {
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
if (ancestor->used_values_per_layout_node[serial_id])
return *ancestor->used_values_per_layout_node[serial_id];
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: 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: 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
auto const* containing_block_used_values = box.is_viewport() ? nullptr : &get(*box.containing_block());
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: 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
const_cast<LayoutState*>(this)->used_values_per_layout_node[serial_id] = adopt_own(*new UsedValues);
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
const_cast<LayoutState*>(this)->used_values_per_layout_node[serial_id]->set_node(const_cast<NodeWithStyleAndBoxModelMetrics&>(box), containing_block_used_values);
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
return *used_values_per_layout_node[serial_id];
LibWeb: Use copy-on-write to make cloning a FormattingState much cheaper Instead of making a full copy of every NodeState when cloning a FormattingState, we make NodeState ref-counted and implement a basic copy-on-write mechanism. FormattingState::get_mutable() now makes a deep copy of the NodeState when first accessed *if* it is shared with other FormattingStates.
2022-02-28 12:32:23 +01:00
}
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
void LayoutState::commit()
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: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
// Only the top-level LayoutState should ever be committed.
LibWeb: Make Layout::FormattingState copies shallow Previously, each NodeState in a FormattingState was shared with the parent FormattingState, but the HashMap of NodeState had to be copied when making FormattingState copies. This patch makes copying instant by keeping a pointer to the parent FormattingState instead. When fetching immutable state via get(), we may now return a reference to a NodeState owned by a parent FormattingState. get_mutable() will copy any NodeState found in the ancestor chain before making a brand new one.
2022-03-12 16:33:11 +01:00
VERIFY(!m_parent);
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
HashTable<Layout::TextNode*> text_nodes;
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
for (auto& used_values_ptr : used_values_per_layout_node) {
if (!used_values_ptr)
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
continue;
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
auto& used_values = *used_values_ptr;
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
auto& node = const_cast<NodeWithStyleAndBoxModelMetrics&>(used_values.node());
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
// Transfer box model metrics.
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
node.box_model().inset = { used_values.inset_top.value(), used_values.inset_right.value(), used_values.inset_bottom.value(), used_values.inset_left.value() };
node.box_model().padding = { used_values.padding_top.value(), used_values.padding_right.value(), used_values.padding_bottom.value(), used_values.padding_left.value() };
node.box_model().border = { used_values.border_top.value(), used_values.border_right.value(), used_values.border_bottom.value(), used_values.border_left.value() };
node.box_model().margin = { used_values.margin_top.value(), used_values.margin_right.value(), used_values.margin_bottom.value(), used_values.margin_left.value() };
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: 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
node.set_paintable(node.create_paintable());
LibWeb: Add Painting::Box and move things from Layout::Box into it The "paintable" state in Layout::Box was actually not safe to access until after layout had been performed. As a first step towards making this harder to mess up accidentally, this patch moves painting information from Layout::Box to a new class: Painting::Box. Every layout can have a corresponding paint box, and it holds the final used metrics determined by layout. The paint box is created and populated by FormattingState::commit(). I've also added DOM::Node::paint_box() as a convenient way to access the paint box (if available) of a given DOM node. Going forward, I believe this will allow us to better separate data that belongs to layout vs painting, and also open up opportunities for naturally invalidating caches in the paint box (since it's reconstituted by every layout.)
2022-03-09 23:53:41 +01:00
// For boxes, transfer all the state needed for painting.
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
if (is<Layout::Box>(node)) {
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
auto& box = static_cast<Layout::Box const&>(node);
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
auto& paint_box = const_cast<Painting::PaintableBox&>(*box.paint_box());
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
paint_box.set_offset(used_values.offset);
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
paint_box.set_content_size(used_values.content_width(), used_values.content_height());
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
paint_box.set_overflow_data(move(used_values.overflow_data));
paint_box.set_containing_line_box_fragment(used_values.containing_line_box_fragment);
LibWeb: Make Painting::Box virtual and add Painting::BoxWithLines BlockContainer paint boxes are the only ones that have line boxes associated, so let's not waste memory on line boxes in all the other types of boxes. This also adds Layout::Box::paint_box() and the more tightly typed Layout::BlockContainer::paint_box() to get at the paint box from the corresponding layout box.
2022-03-10 11:12:06 +01:00
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
if (is<Layout::BlockContainer>(box)) {
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
for (auto& line_box : used_values.line_boxes) {
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
for (auto& fragment : line_box.fragments()) {
if (fragment.layout_node().is_text_node())
text_nodes.set(static_cast<Layout::TextNode*>(const_cast<Layout::Node*>(&fragment.layout_node())));
}
}
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
static_cast<Painting::PaintableWithLines&>(paint_box).set_line_boxes(move(used_values.line_boxes));
LibWeb: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
}
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: Generate a TextPaintable for every Layout::TextNode This is prep work for moving event handling over to the painting tree.
2022-03-10 16:46:44 +01:00
for (auto* text_node : text_nodes)
text_node->set_paintable(text_node->create_paintable());
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 box_baseline(LayoutState const& state, Box const& box)
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
{
auto const& box_state = state.get(box);
LibWeb: Use TextTop and TextBottom property for VerticalAlign If text-top or text-bottom are given as values for the vertical-align property, actually use them and calculate the respective position of the element. The actual calculations done (using the font_size, descent, etc.) are not exactly how I imagined them when reading the spec, but the results seem acceptable when compared to other browsers.
2023-01-01 14:50:52 +01:00
// https://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
auto const& vertical_align = box.computed_values().vertical_align();
if (vertical_align.has<CSS::VerticalAlign>()) {
switch (vertical_align.get<CSS::VerticalAlign>()) {
case CSS::VerticalAlign::Top:
LibWeb: Use TextTop and TextBottom property for VerticalAlign If text-top or text-bottom are given as values for the vertical-align property, actually use them and calculate the respective position of the element. The actual calculations done (using the font_size, descent, etc.) are not exactly how I imagined them when reading the spec, but the results seem acceptable when compared to other browsers.
2023-01-01 14:50:52 +01:00
// Top: Align the top of the aligned subtree with the top of the line box.
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
return box_state.border_box_top();
case CSS::VerticalAlign::Bottom:
LibWeb: Use TextTop and TextBottom property for VerticalAlign If text-top or text-bottom are given as values for the vertical-align property, actually use them and calculate the respective position of the element. The actual calculations done (using the font_size, descent, etc.) are not exactly how I imagined them when reading the spec, but the results seem acceptable when compared to other browsers.
2023-01-01 14:50:52 +01:00
// Bottom: Align the bottom of the aligned subtree with the bottom of the line box.
LibWeb: Consider margins of atomic inlines in layout According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic inlines should be layed out in a line box based on their margin box. However, up until this patch we were unconditionally considering only the border box during line box height calculation. This made us essentially drop all vertical margins for atomic inlines.
2023-03-14 10:28:01 +01:00
return box_state.content_height() + box_state.margin_box_top();
LibWeb: Use TextTop and TextBottom property for VerticalAlign If text-top or text-bottom are given as values for the vertical-align property, actually use them and calculate the respective position of the element. The actual calculations done (using the font_size, descent, etc.) are not exactly how I imagined them when reading the spec, but the results seem acceptable when compared to other browsers.
2023-01-01 14:50:52 +01:00
case CSS::VerticalAlign::TextTop:
// TextTop: Align the top of the box with the top of the parent's content area (see 10.6.1).
return box.computed_values().font_size();
case CSS::VerticalAlign::TextBottom:
// TextTop: Align the bottom of the box with the bottom of the parent's content area (see 10.6.1).
return box_state.content_height() - (box.containing_block()->font().pixel_metrics().descent * 2);
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
default:
break;
}
}
if (!box_state.line_boxes.is_empty())
LibWeb: Consider margins of atomic inlines in layout According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic inlines should be layed out in a line box based on their margin box. However, up until this patch we were unconditionally considering only the border box during line box height calculation. This made us essentially drop all vertical margins for atomic inlines.
2023-03-14 10:28:01 +01:00
return box_state.margin_box_top() + box_state.offset.y() + box_state.line_boxes.last().baseline();
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
if (box.has_children() && !box.children_are_inline()) {
auto const* child_box = box.last_child_of_type<Box>();
VERIFY(child_box);
return box_baseline(state, *child_box);
}
LibWeb: Consider margins of atomic inlines in layout According to CSS Inline Layout Module Level 3 § 2.2 Step 1. atomic inlines should be layed out in a line box based on their margin box. However, up until this patch we were unconditionally considering only the border box during line box height calculation. This made us essentially drop all vertical margins for atomic inlines.
2023-03-14 10:28:01 +01:00
return box_state.margin_box_height();
LibWeb: Move box_baseline from LineBuilder.cpp to LayoutState.cpp
2022-12-04 19:51:29 +03:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect margin_box_rect(Box const& box, LayoutState const& state)
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
{
auto const& box_state = state.get(box);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto rect = CSSPixelRect { box_state.offset, { box_state.content_width(), box_state.content_height() } };
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
rect.set_x(rect.x() - box_state.margin_box_left());
rect.set_width(rect.width() + box_state.margin_box_left() + box_state.margin_box_right());
rect.set_y(rect.y() - box_state.margin_box_top());
rect.set_height(rect.height() + box_state.margin_box_top() + box_state.margin_box_bottom());
return rect;
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect border_box_rect(Box const& box, LayoutState const& state)
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
{
auto const& box_state = state.get(box);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto rect = CSSPixelRect { box_state.offset, { box_state.content_width(), box_state.content_height() } };
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
rect.set_x(rect.x() - box_state.border_box_left());
rect.set_width(rect.width() + box_state.border_box_left() + box_state.border_box_right());
rect.set_y(rect.y() - box_state.border_box_top());
rect.set_height(rect.height() + box_state.border_box_top() + box_state.border_box_bottom());
return rect;
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect border_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box, LayoutState const& state)
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
{
auto rect = border_box_rect(box, state);
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
if (&box == &ancestor_box)
return rect;
for (auto const* current = box.containing_block(); current; current = current->containing_block()) {
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
if (current == &ancestor_box)
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
return rect;
auto const& current_state = state.get(static_cast<Box const&>(*current));
rect.translate_by(current_state.offset);
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
}
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
LibWeb: Improve `float: right` behavior - Use the border box of the floated element when testing if something needs to flow around it. - Take the floated element's containing block size into account (instead of the BFC root) when calculating available space on a line where a right-side float intrudes.
2022-09-07 13:29:58 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect content_box_rect(Box const& box, LayoutState const& state)
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
{
auto const& box_state = state.get(box);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
return CSSPixelRect { box_state.offset, { box_state.content_width(), box_state.content_height() } };
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect content_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box, LayoutState const& state)
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
{
auto rect = content_box_rect(box, state);
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
if (&box == &ancestor_box)
return rect;
for (auto const* current = box.containing_block(); current; current = current->containing_block()) {
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
if (current == &ancestor_box)
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
return rect;
auto const& current_state = state.get(static_cast<Box const&>(*current));
rect.translate_by(current_state.offset);
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
}
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
LibWeb: Use correct box edge when looking for space between floats
2022-09-08 13:21:57 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect margin_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box, LayoutState const& state)
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
{
auto rect = margin_box_rect(box, state);
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
if (&box == &ancestor_box)
return rect;
for (auto const* current = box.containing_block(); current; current = current->containing_block()) {
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
if (current == &ancestor_box)
LibWeb: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
return rect;
auto const& current_state = state.get(static_cast<Box const&>(*current));
rect.translate_by(current_state.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: Only include containing blocks in coordinate space translation Layout box offset coordinates are always relative to their containing block. Therefore, the functions that convert between coordinate spaces should only visit containing blocks and apply their offsets, not *every* box in the parent chain. This fixes an issue where some floating boxes were unexpectedly far away from their containing block.
2022-09-22 14:17:11 +02:00
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
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
CSSPixelRect absolute_content_rect(Box const& box, LayoutState const& state)
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
{
auto const& box_state = state.get(box);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixelRect rect { box_state.offset, { box_state.content_width(), box_state.content_height() } };
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
for (auto* block = box.containing_block(); block; block = block->containing_block())
rect.translate_by(state.get(*block).offset);
return rect;
}
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
void LayoutState::UsedValues::set_node(NodeWithStyleAndBoxModelMetrics& node, UsedValues const* containing_block_used_values)
{
m_node = &node;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
// NOTE: In the code below, we decide if `node` has definite width and/or height.
// This attempts to cover all the *general* cases where CSS considers sizes to be definite.
// If `node` has definite values for min/max-width or min/max-height and a definite
// preferred size in the same axis, we clamp the preferred size here as well.
//
// There are additional cases where CSS considers values to be definite. We model all of
// those by having our engine consider sizes to be definite *once they are assigned to
// the UsedValues by calling set_content_width() or set_content_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
auto const& computed_values = node.computed_values();
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto is_definite_size = [&](CSS::Size const& size, CSSPixels& resolved_definite_size, bool width) {
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
// A size that can be determined without performing layout; that is,
// a <length>,
// a measure of text (without consideration of line-wrapping),
// a size of the initial containing block,
// or a <percentage> or other formula (such as the “stretch-fit” sizing of non-replaced blocks [CSS2]) that is resolved solely against definite sizes.
auto containing_block_has_definite_size = containing_block_used_values ? (width ? containing_block_used_values->has_definite_width() : containing_block_used_values->has_definite_height()) : false;
if (size.is_auto()) {
// NOTE: The width of a non-flex-item block is considered definite if it's auto and the containing block has definite width.
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
if (width
LibWeb: Floating boxes with width:auto don't have definite width Since layout is required in order to determine the width of such boxes, they should not be marked as having definite width initially.
2022-10-07 13:07:40 +02:00
&& !node.is_floating()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& node.display().is_block_outside()
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
&& node.parent()
&& !node.parent()->is_floating()
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
&& (node.parent()->display().is_flow_root_inside()
|| node.parent()->display().is_flow_inside())) {
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (containing_block_has_definite_size) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels available_width = containing_block_used_values->content_width();
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
resolved_definite_size = available_width
- margin_left
- margin_right
- padding_left
- padding_right
- border_left
- border_right;
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
return true;
}
return false;
}
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
return false;
}
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
if (size.is_length() && size.length().is_calculated()) {
LibWeb: Mark percentage heights as initially definite when appropriate Percentage heights are now considered definite when their containing block has a definite height. This makes profile pictures have geometry on Twitter. (We still don't load the images themselves though.)
2022-10-13 11:16:54 +02:00
if (size.length().calculated_style_value()->contains_percentage()) {
if (!containing_block_has_definite_size)
return false;
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
auto& calc_value = *size.length().calculated_style_value();
LibWeb: Mark percentage heights as initially definite when appropriate Percentage heights are now considered definite when their containing block has a definite height. This makes profile pictures have geometry on Twitter. (We still don't load the images themselves though.)
2022-10-13 11:16:54 +02:00
auto containing_block_size_as_length = width
? CSS::Length::make_px(containing_block_used_values->content_width())
: CSS::Length::make_px(containing_block_used_values->content_height());
resolved_definite_size = calc_value.resolve_length_percentage(node, containing_block_size_as_length).value_or(CSS::Length::make_auto()).to_px(node);
return true;
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
}
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
resolved_definite_size = size.length().to_px(node);
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
return true;
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
}
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
if (size.is_length()) {
VERIFY(!size.is_auto()); // This should have been covered by the Size::is_auto() branch above.
VERIFY(!size.length().is_calculated()); // Covered above.
resolved_definite_size = size.length().to_px(node);
return true;
}
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
if (size.is_percentage()) {
if (containing_block_has_definite_size) {
auto containing_block_size = width ? containing_block_used_values->content_width() : containing_block_used_values->content_height();
resolved_definite_size = containing_block_size * size.percentage().as_fraction();
return true;
}
return false;
}
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
// FIXME: Determine if calc() value is definite.
return false;
};
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_width = is_definite_size(computed_values.min_width(), min_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_width = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_width = is_definite_size(computed_values.max_width(), max_width, true);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels min_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_min_height = is_definite_size(computed_values.min_height(), min_height, false);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels max_height = 0;
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
bool has_definite_max_height = is_definite_size(computed_values.max_height(), max_height, false);
LibWeb: Resolve definite sizes when instantiating UsedValues When we decide that a box has definite width or height based on its containing block's corresponding size, we'll want to resolve the current box's size as well. Otherwise anyone querying the size on this box will get the bogus message of "yes, this definite, and its value is zero."
2022-07-19 13:46:27 +02:00
m_has_definite_width = is_definite_size(computed_values.width(), m_content_width, true);
m_has_definite_height = is_definite_size(computed_values.height(), m_content_height, false);
LibWeb: Apply min/max constraints to sizes that are initially definite Also add a comment explaining how we determine initial definite sizes.
2022-10-13 14:49:08 +02:00
if (m_has_definite_width) {
if (has_definite_min_width)
m_content_width = max(min_width, m_content_width);
if (has_definite_max_width)
m_content_width = min(max_width, m_content_width);
}
if (m_has_definite_height) {
if (has_definite_min_height)
m_content_height = max(min_height, m_content_height);
if (has_definite_max_height)
m_content_height = min(max_height, m_content_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
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_width(CSSPixels width)
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: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (width < 0) {
// Negative heights are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
dbgln("FIXME: Layout calculated a negative width for {}: {}", m_node->debug_description(), width);
width = 0;
}
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
m_content_width = width;
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
m_has_definite_width = true;
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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_height(CSSPixels height)
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: Add FIXME whining to debug log if layout produces negative sizes Negative width/height sizes are not allowed in CSS, so if our layout algorithm resolves something to a negative size, we have boogs. Instead of crashing or rendering something very wrong, we now clamp the values to 0 and whine on the debug log so that someone can go and figure out how we got the negative values in the first place. :^)
2023-03-25 17:33:22 +01:00
if (height < 0) {
// Negative heights are not allowed in CSS. We have a bug somewhere! Clamp to 0 to avoid doing too much damage.
dbgln("FIXME: Layout calculated a negative height for {}: {}", m_node->debug_description(), height);
height = 0;
}
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
m_content_height = height;
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
m_has_definite_height = true;
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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_temporary_content_width(CSSPixels width)
LibWeb: Assign hypothetical flex item main sizes as temporary main size This colors a bit outside the lines of the specification, but the spec doesn't offer a proper explanation for how descendants of a flex item are supposed to have access to the flex item's main size for purposes of percentage resolution. The approach I came up with here was to take the hypothetical main size of each flex item, and assign it as a temporary main size. This allows percentage resolution in descendants to work against the pre-flexing main size of items. This seems to match how other engines behave, although it feels somewhat dirty. If/when we learn more about this, we can come up with something nicer.
2022-10-15 09:26:30 +02:00
{
m_content_width = width;
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_temporary_content_height(CSSPixels height)
LibWeb: Assign hypothetical flex item main sizes as temporary main size This colors a bit outside the lines of the specification, but the spec doesn't offer a proper explanation for how descendants of a flex item are supposed to have access to the flex item's main size for purposes of percentage resolution. The approach I came up with here was to take the hypothetical main size of each flex item, and assign it as a temporary main size. This allows percentage resolution in descendants to work against the pre-flexing main size of items. This seems to match how other engines behave, although it feels somewhat dirty. If/when we learn more about this, we can come up with something nicer.
2022-10-15 09:26:30 +02:00
{
m_content_height = height;
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels LayoutState::resolved_definite_width(Box const& box) const
LibWeb: Don't re-resolve "auto" flex item sizes after definitizing them This is rather subtle and points to our architecture around definite sizes not being exactly right, but... At some points during flexbox layout, the spec tells us that the sizes of certain flex items are considered definite from this point on. We implement this by marking each item's associated UsedValues as "has-definite-width/height". However, this breaks code that tries to resolve computed "auto" sizes by taking the corresponding size from the containing block. The end result was that the 1st sizing pass in flexbox would find the right size for an "auto" sized item, but the 2nd pass would override the correct size with the containing block's content size in that axis instead. To work around the issue, FFC now remembers when it "definitizes" an item, and future attempts to resolve an "auto" computed size for that value will bypass the computed-auto-is-resolved-against-containing-block step of the algorithm. It's not perfect, and we'll need to think more about how to really represent these intermediate states relating to box sizes being definite..
2022-09-14 11:43:57 +02:00
{
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
return get(box).content_width();
LibWeb: Don't re-resolve "auto" flex item sizes after definitizing them This is rather subtle and points to our architecture around definite sizes not being exactly right, but... At some points during flexbox layout, the spec tells us that the sizes of certain flex items are considered definite from this point on. We implement this by marking each item's associated UsedValues as "has-definite-width/height". However, this breaks code that tries to resolve computed "auto" sizes by taking the corresponding size from the containing block. The end result was that the 1st sizing pass in flexbox would find the right size for an "auto" sized item, but the 2nd pass would override the correct size with the containing block's content size in that axis instead. To work around the issue, FFC now remembers when it "definitizes" an item, and future attempts to resolve an "auto" computed size for that value will bypass the computed-auto-is-resolved-against-containing-block step of the algorithm. It's not perfect, and we'll need to think more about how to really represent these intermediate states relating to box sizes being definite..
2022-09-14 11:43:57 +02:00
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels LayoutState::resolved_definite_height(Box const& box) const
LibWeb: Don't re-resolve "auto" flex item sizes after definitizing them This is rather subtle and points to our architecture around definite sizes not being exactly right, but... At some points during flexbox layout, the spec tells us that the sizes of certain flex items are considered definite from this point on. We implement this by marking each item's associated UsedValues as "has-definite-width/height". However, this breaks code that tries to resolve computed "auto" sizes by taking the corresponding size from the containing block. The end result was that the 1st sizing pass in flexbox would find the right size for an "auto" sized item, but the 2nd pass would override the correct size with the containing block's content size in that axis instead. To work around the issue, FFC now remembers when it "definitizes" an item, and future attempts to resolve an "auto" computed size for that value will bypass the computed-auto-is-resolved-against-containing-block step of the algorithm. It's not perfect, and we'll need to think more about how to really represent these intermediate states relating to box sizes being definite..
2022-09-14 11:43:57 +02:00
{
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
return get(box).content_height();
}
AvailableSize LayoutState::UsedValues::available_width_inside() const
{
if (width_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (width_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_width())
return AvailableSize::make_definite(m_content_width);
return AvailableSize::make_indefinite();
}
AvailableSize LayoutState::UsedValues::available_height_inside() const
{
if (height_constraint == SizeConstraint::MinContent)
return AvailableSize::make_min_content();
if (height_constraint == SizeConstraint::MaxContent)
return AvailableSize::make_max_content();
if (has_definite_height())
return AvailableSize::make_definite(m_content_height);
return AvailableSize::make_indefinite();
}
AvailableSpace LayoutState::UsedValues::available_inner_space_or_constraints_from(AvailableSpace const& outer_space) const
{
auto inner_width = available_width_inside();
auto inner_height = available_height_inside();
if (inner_width.is_indefinite() && outer_space.width.is_intrinsic_sizing_constraint())
inner_width = outer_space.width;
if (inner_height.is_indefinite() && outer_space.height.is_intrinsic_sizing_constraint())
inner_height = outer_space.height;
return AvailableSpace(inner_width, inner_height);
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_offset(CSSPixelPoint new_offset)
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
{
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
set_content_x(new_offset.x());
set_content_y(new_offset.y());
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
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_x(CSSPixels x)
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
{
offset.set_x(x);
}
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
void LayoutState::UsedValues::set_content_y(CSSPixels y)
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
{
offset.set_y(y);
LibWeb: Don't re-resolve "auto" flex item sizes after definitizing them This is rather subtle and points to our architecture around definite sizes not being exactly right, but... At some points during flexbox layout, the spec tells us that the sizes of certain flex items are considered definite from this point on. We implement this by marking each item's associated UsedValues as "has-definite-width/height". However, this breaks code that tries to resolve computed "auto" sizes by taking the corresponding size from the containing block. The end result was that the 1st sizing pass in flexbox would find the right size for an "auto" sized item, but the 2nd pass would override the correct size with the containing block's content size in that axis instead. To work around the issue, FFC now remembers when it "definitizes" an item, and future attempts to resolve an "auto" computed size for that value will bypass the computed-auto-is-resolved-against-containing-block step of the algorithm. It's not perfect, and we'll need to think more about how to really represent these intermediate states relating to box sizes being definite..
2022-09-14 11:43:57 +02:00
}
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
}
Reference in a new issue Copy permalink