dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/Layout/FormattingContext.h

171 lines
7.6 KiB
C
Raw Normal View History

LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020-2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
*/
#pragma once
LibWeb: Add missing headers
2021-10-10 10:56:29 -03:00
#include <AK/OwnPtr.h>
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
#include <LibWeb/Forward.h>
LibWeb: Make FormattingContext::run() take available space as input Instead of formatting contexts flailing around to figure out from the "inside" how much space is available on the "outside", we should provide the amount of available space in both axes as an input to run(). This basically means that when something creates a nested formatting context, the parent context is responsible for telling the nested context how much space is available for layout. This information is provided immediately when invoking run(). Note that this commit doesn't pass accurate values in all cases yet. This first step just makes it build, and passes available values in some cases where getting them was trivial.
2022-09-25 14:12:09 -03:00
#include <LibWeb/Layout/AvailableSpace.h>
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03:00
#include <LibWeb/Layout/LayoutState.h>
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
namespace Web::Layout {
LibWeb: Move css_clamp function to FormattingContext Since we need it in the FlexFormattingContext and GridFormatting context now.
2024-07-24 04:17:47 -03:00
// NOTE: We use a custom clamping function here instead of AK::clamp(), since the AK version
// will VERIFY(max >= min) and CSS explicitly allows that (see css-values-4.)
template<typename T>
[[nodiscard]] constexpr T css_clamp(T const& value, T const& min, T const& max)
{
return ::max(min, ::min(value, max));
}
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
class FormattingContext {
public:
LibWeb: Factor out creation of independent formatting contexts This patch breaks FormattingContext::layout_inside() into two functions, one that creates an independent formatting context (if needed), and another that calls the former and then performs the inside layout within the appropriate context. The main goal here was to make layout_inside() return the independent formatting context if one was created. This will allow us to defer certain operations in child contexts until the parent context has finished formatting the child root box.
2021-10-17 13:24:07 -03:00
virtual ~FormattingContext();
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
enum class Type {
Block,
Inline,
Flex,
LibWeb: Make grid containers be Layout::Box Grid containers were incorrectly represented as BlockContainer before. Furthermore, GridFormattingContext had a bogus inheritance relationship with BlockFormattingContext. This patch brings our architecture closer to spec by making grid containers be plain boxes and making GFC not inherit from BFC.
2023-01-23 11:19:32 -03:00
Grid,
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
Table,
SVG,
LibWeb: Show formatting context roots in layout tree dumps This patch does three things: - Factors out the code that determines whether a box will create a new formatting context for its children (and which type of context) - Uses that code to mark all formatting context roots in layout tree dumps. This makes it much easier to follow along with layout since you can now see exactly where control is transferred to a new formatting context. - Rebaselines all existing layout tests, since the output format has changed slightly.
2023-05-03 05:32:23 -03:00
InternalReplaced, // Internal hack formatting context for replaced elements. FIXME: Get rid of this.
InternalDummy, // Internal hack formatting context for unimplemented things. FIXME: Get rid of this.
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
};
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
virtual void run(AvailableSpace const&) = 0;
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 10:29:17 -03:00
// This function returns the automatic content height of the context's root box.
LibWeb: Let FormattingContext decide the automatic width of its root Instead of special-casing FlexFormattingContext in the intrinsic sizing layout helpers, add FormattingContext::automatic_content_width() and let each context subclass decide what that means. No behavior change here, just moving this responsibility.
2023-03-19 05:57:31 -03:00
virtual CSSPixels automatic_content_width() const = 0;
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
LibWeb: Add FormattingContext::automatic_content_height() This function should return the automatic height of the formatting context's root box. Until now, we've been relying on some magical handshakes between parent and child context, when negotiating the height of child context root boxes. This is a step towards something more reasonable.
2022-09-24 08:39:43 -03:00
// This function returns the automatic content height of the context's root box.
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
virtual CSSPixels automatic_content_height() const = 0;
LibWeb: Add FormattingContext::automatic_content_height() This function should return the automatic height of the formatting context's root box. Until now, we've been relying on some magical handshakes between parent and child context, when negotiating the height of child context root boxes. This is a step towards something more reasonable.
2022-09-24 08:39:43 -03: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 11:51:24 -03:00
Box const& context_box() const { return m_context_box; }
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
LibWeb: Keep track of the parent of each formatting context This will allow us to find the containing block formatting context when needed later on.
2020-11-25 16:08:52 -03:00
FormattingContext* parent() { return m_parent; }
Everywhere: Run clang-format
2022-04-01 14:58:27 -03:00
FormattingContext const* parent() const { return m_parent; }
LibWeb: Keep track of the parent of each formatting context This will allow us to find the containing block formatting context when needed later on.
2020-11-25 16:08:52 -03:00
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
Type type() const { return m_type; }
LibWeb: Implement "out-of-flow" property of Layout Box In some situations, a layout box should not participate in the standard layout process, for example when set to `position: absolute`.
2021-09-15 08:19:42 -03:00
virtual bool inhibits_floating() const { return false; }
LibWeb: First slightly naive implementation of CSS floats :^) Boxes can now be floated left or right, which makes text within the same block formatting context flow around them. We were creating way too many block formatting contexts. As it turns out, we don't need one for every new block, but rather there's a set of rules that determines whether a given block creates a new block formatting context. Each BFC keeps track of the floating boxes within it, and IFC's can then query it to find the available space for line boxes. There's a huge hack in here where we assume all lines are the exact line-height. Making this work with vertically non-uniform lines will require some architectural changes.
2020-12-05 16:10:39 -03:00
LibWeb: Show formatting context roots in layout tree dumps This patch does three things: - Factors out the code that determines whether a box will create a new formatting context for its children (and which type of context) - Uses that code to mark all formatting context roots in layout tree dumps. This makes it much easier to follow along with layout since you can now see exactly where control is transferred to a new formatting context. - Rebaselines all existing layout tests, since the output format has changed slightly.
2023-05-03 05:32:23 -03:00
[[nodiscard]] static Optional<Type> formatting_context_type_created_by_box(Box const&);
Everywhere: Run clang-format
2022-04-01 14:58:27 -03:00
static bool creates_block_formatting_context(Box const&);
LibWeb: First slightly naive implementation of CSS floats :^) Boxes can now be floated left or right, which makes text within the same block formatting context flow around them. We were creating way too many block formatting contexts. As it turns out, we don't need one for every new block, but rather there's a set of rules that determines whether a given block creates a new block formatting context. Each BFC keeps track of the floating boxes within it, and IFC's can then query it to find the available space for line boxes. There's a huge hack in here where we assume all lines are the exact line-height. Making this work with vertically non-uniform lines will require some architectural changes.
2020-12-05 16:10:39 -03:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 15:11:04 -03:00
CSSPixels compute_table_box_width_inside_table_wrapper(Box const&, AvailableSpace const&);
CSSPixels compute_table_box_height_inside_table_wrapper(Box const&, AvailableSpace const&);
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 12:47:50 -03:00
CSSPixels compute_width_for_replaced_element(Box const&, AvailableSpace const&) const;
CSSPixels compute_height_for_replaced_element(Box const&, AvailableSpace const&) const;
LibWeb: Move replaced element layout out of Layout::ReplacedBox Replaced elements are now laid out by the current formatting context. Since the logic is almost identical in BFC and IFC, it's implemented by static helpers in FormattingContext.
2020-12-11 18:27:09 -03:00
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
OwnPtr<FormattingContext> create_independent_formatting_context_if_needed(LayoutState&, LayoutMode, Box const& child_box);
LibWeb: Factor out creation of independent formatting contexts This patch breaks FormattingContext::layout_inside() into two functions, one that creates an independent formatting context (if needed), and another that calls the former and then performs the inside layout within the appropriate context. The main goal here was to make layout_inside() return the independent formatting context if one was created. This will allow us to defer certain operations in child contexts until the parent context has finished formatting the child root box.
2021-10-17 13:24:07 -03:00
LibWeb: Stop sizing the context root box in formatting contexts Until now, some formatting contexts (BFC in particular) have been assigning size to the root box. This is really the responsibility of the parent formatting context, so let's stop doing it. To keep position:absolute working, parent formatting contexts now notify child contexts when the child's root box has been sized. (Note that the important thing here is for the child root to have its final used height before it's able to place bottom-relative boxes.) This breaks flexbox layout in some ways, but we'll have to address those by improving the spec compliance of FFC.)
2022-02-12 15:54:09 -03:00
virtual void parent_context_did_dimension_child_root_box() { }
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
CSSPixels calculate_min_content_width(Layout::Box const&) const;
CSSPixels calculate_max_content_width(Layout::Box const&) const;
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 10:17:17 -03:00
CSSPixels calculate_min_content_height(Layout::Box const&, CSSPixels width) const;
CSSPixels calculate_max_content_height(Layout::Box const&, CSSPixels width) const;
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 10:36:59 -03:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
CSSPixels calculate_fit_content_height(Layout::Box const&, AvailableSpace const&) const;
CSSPixels calculate_fit_content_width(Layout::Box const&, AvailableSpace const&) const;
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 10:36:59 -03:00
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 01:24:09 -03:00
CSSPixels calculate_inner_width(Layout::Box const&, AvailableSize const&, CSS::Size const& width) const;
LibWeb: Resolve "height: auto" using preferred aspect ratio if possible Fixes https://github.com/LadybirdBrowser/ladybird/issues/2276
2025-03-14 16:20:34 -03:00
[[nodiscard]] CSSPixels calculate_inner_height(Box const&, AvailableSpace const&, CSS::Size const& height) const;
LibWeb: Support box-sizing in BFC Add support for box-sizing in block formatting context, support for Flex Formatting Context and Grid Formatting Context is missing
2022-11-21 16:17:24 -03:00
LibWeb: Let FormattingContext decide the automatic width of its root Instead of special-casing FlexFormattingContext in the intrinsic sizing layout helpers, add FormattingContext::automatic_content_width() and let each context subclass decide what that means. No behavior change here, just moving this responsibility.
2023-03-19 05:57:31 -03:00
virtual CSSPixels greatest_child_width(Box const&) const;
LibWeb: Rewrite CSS float implementation to use offset-from-edge The previous implementation used relative X offsets for both left and right-side floats. This made right-side floats super awkward, since we could only determine their X position once the width of the BFC root was known, and for BFC roots with automatic width, this was not even working at all most of the time. This patch changes the way we deal with floats so that BFC keeps track of the offset-from-edge for each float. The offset is the distance from the BFC root edge (left or right, depending on float direction) to the "innermost" margin edge of the floating box. Floating box are now laid out in two passes: while going through the normal flow layout, we put floats in their *static* position (i.e the position they would have occupied if they weren't floating) and then update the Y position value to the final one. The second pass occurs later on, when the BFC root has had its width assigned by the parent context. Once we know the root width, we can set the X position value of floating boxes. (Because the X position of right-side floats is relative to the right edge of the BFC root.)
2022-03-18 10:44:36 -03:00
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 05:18:34 -03:00
[[nodiscard]] CSSPixelRect absolute_content_rect(Box const&) const;
[[nodiscard]] CSSPixelRect margin_box_rect_in_ancestor_coordinate_space(Box const&, Box const& ancestor_box) const;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 07:24:41 -03:00
[[nodiscard]] CSSPixelRect margin_box_rect_in_ancestor_coordinate_space(LayoutState::UsedValues const&, Box const& ancestor_box) const;
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 05:18:34 -03:00
[[nodiscard]] CSSPixelRect content_box_rect(Box const&) const;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 07:24:41 -03:00
[[nodiscard]] CSSPixelRect content_box_rect(LayoutState::UsedValues const&) const;
[[nodiscard]] CSSPixelRect content_box_rect_in_ancestor_coordinate_space(LayoutState::UsedValues const&, Box const& ancestor_box) const;
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 05:18:34 -03:00
[[nodiscard]] CSSPixels box_baseline(Box const&) const;
[[nodiscard]] CSSPixelRect content_box_rect_in_static_position_ancestor_coordinate_space(Box const&, Box const& ancestor_box) const;
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 04:30:13 -03:00
[[nodiscard]] CSSPixels containing_block_width_for(NodeWithStyleAndBoxModelMetrics const&) const;
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 10:17:47 -03:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
[[nodiscard]] CSSPixels calculate_stretch_fit_width(Box const&, AvailableSize const&) const;
[[nodiscard]] CSSPixels calculate_stretch_fit_height(Box const&, AvailableSize const&) const;
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 10:29:17 -03:00
LibWeb: Refactor should_skip_anonymous_text_runs This same function was being copied in the {Flex,Grid}FormattingContext, so unify them in the parent FormattingContext.
2022-12-28 06:11:54 -03:00
bool can_skip_is_anonymous_text_run(Box&);
LibWeb: Improve placement of abspos boxes with dual-auto insets When an absolutely positioned box has auto insets on both sides of an axis, it's placed according to the "static position rectangle". This is, roughly, the rectangle a box would occupy if it were position:static instead of position:absolute or position:fixed. This patch implements a rough, but still significantly better, estimation of such static positions. It gets pretty hairy in the case where an abspos box has a parent whose children are inline.
2022-10-01 08:48:28 -03:00
LibWeb: Fix percentage insets resolution for grid items compute_inset() was incorrectly retrieving the containing block size because containing_block() is unaware of grid areas that form a containing block for grid items but do not exist in the layout tree. With this change, we explicitly pass the containing block into compute_inset(), allowing it to correctly provide the containing block sizes for grid items.
2024-11-11 11:54:21 -03:00
void compute_inset(NodeWithStyleAndBoxModelMetrics const&, CSSPixelSize containing_block_size);
LibWeb: Resolve CSS inset properties when entering inline-flow elements We don't actually apply the insets anywhere yet, but at least now they are available in the node's layout state.
2023-08-15 04:34:06 -03:00
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
protected:
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
FormattingContext(Type, LayoutMode, LayoutState&, Box const&, FormattingContext* parent = nullptr);
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
LibWeb: Stop treating intrinsic size keywords as `auto` in CSS heights This commit introduces proper handling of three intrinsic size keywords when used for CSS heights: - min-content - max-content - fit-content This necessitated a few plumbing changes, since we can't resolve these values without having access to containing block widths. This fixes some visual glitches on https://www.supabase.com/ as well as a number of WPT tests. It also improves the appearance of dialogs.
2024-11-21 13:32:02 -03:00
[[nodiscard]] bool should_treat_width_as_auto(Box const&, AvailableSpace const&) const;
[[nodiscard]] bool should_treat_height_as_auto(Box const&, AvailableSpace const&) const;
LibWeb: Move should_treat_{width,height}_as_auto() to FormattingContext These are not specific to BFC, so let's move them up to the super class so that other layout classes can use them.
2022-11-03 14:44:40 -03:00
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 08:46:55 -03:00
[[nodiscard]] bool should_treat_max_width_as_none(Box const&, AvailableSize const&) const;
[[nodiscard]] bool should_treat_max_height_as_none(Box const&, AvailableSize const&) const;
LibWeb: Treat % max-height as none when containing block size indefinite Fixes #19371
2023-06-14 10:33:06 -03:00
LibWeb: Honor "should treat as auto" cases in aspect-ratio decisions
2025-08-04 10:55:19 -03:00
[[nodiscard]] bool box_is_sized_as_replaced_element(Box const&, AvailableSpace const&) const;
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 10:29:17 -03:00
OwnPtr<FormattingContext> layout_inside(Box const&, LayoutMode, AvailableSpace const&);
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
LibWeb: Rewrite CSS float implementation to use offset-from-edge The previous implementation used relative X offsets for both left and right-side floats. This made right-side floats super awkward, since we could only determine their X position once the width of the BFC root was known, and for BFC roots with automatic width, this was not even working at all most of the time. This patch changes the way we deal with floats so that BFC keeps track of the offset-from-edge for each float. The offset is the distance from the BFC root edge (left or right, depending on float direction) to the "innermost" margin edge of the floating box. Floating box are now laid out in two passes: while going through the normal flow layout, we put floats in their *static* position (i.e the position they would have occupied if they weren't floating) and then update the Y position value to the final one. The second pass occurs later on, when the BFC root has had its width assigned by the parent context. Once we know the root width, we can set the X position value of floating boxes. (Because the X position of right-side floats is relative to the right edge of the BFC root.)
2022-03-18 10:44:36 -03:00
struct SpaceUsedByFloats {
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
CSSPixels left { 0 };
CSSPixels right { 0 };
LibWeb: Move available_space_for_line() from IFC to BFC This is preparation for allowing blocks with their own internal BFC to flow around floating boxes in the parent BFC. Note that IFC still has the available_space_for_line() API, which returns space available within the IFC's own containing block, while the BFC available_space_for_line() returns space available within its root.
2022-03-17 08:30:30 -03:00
};
LibWeb: Fix the x coordinate of a block after a float The margin from the containing blocks shouldn't be included in the amount by which we increment x after a float was places. That coordinate should be relative to the containing block. Fixes the comments layout on https://lobste.rs.
2023-06-13 10:37:15 -03:00
struct SpaceUsedAndContainingMarginForFloats {
// Width for left / right floats, including their own margins.
CSSPixels left_used_space;
CSSPixels right_used_space;
// Left / right total margins from the outermost containing block to the floating element.
// Each block in the containing chain adds its own margin and we store the total here.
CSSPixels left_total_containing_margin;
CSSPixels right_total_containing_margin;
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-14 12:01:23 -03:00
GC::Ptr<Box const> matching_left_float_box;
LibWeb: Correct the calculation for right float intrusion We used to subtract the maximum right margin of any containing box, but we want to subtract the entire right margin instead. This yielded incorrect intrusions for right floats not placed in the root.
2025-05-24 06:46:01 -03:00
GC::Ptr<Box const> matching_right_float_box;
LibWeb: Fix the x coordinate of a block after a float The margin from the containing blocks shouldn't be included in the amount by which we increment x after a float was places. That coordinate should be relative to the containing block. Fixes the comments layout on https://lobste.rs.
2023-06-13 10:37:15 -03:00
};
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
struct ShrinkToFitResult {
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
CSSPixels preferred_width { 0 };
CSSPixels preferred_minimum_width { 0 };
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
};
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 12:47:50 -03:00
CSSPixels tentative_width_for_replaced_element(Box const&, CSS::Size const& computed_width, AvailableSpace const&) const;
CSSPixels tentative_height_for_replaced_element(Box const&, CSS::Size const& computed_height, AvailableSpace const&) const;
LibWeb: Allow BFC auto height calculation on any Layout::Box This algorithm is reused in abspos sizing, and so should not be specific to block containers (even if the name suggests it.)
2023-01-23 10:45:52 -03:00
CSSPixels compute_auto_height_for_block_formatting_context_root(Box const&) const;
LibWeb: Apply 'min-width' and 'max-width' constraints to replaced boxes This is definitely not 100% correct but I tried implementing the basic algorithms described in CSS 2.2. It's good enough to render the penguin on @linusg's homepage at the right size. :^)
2020-12-11 20:20:31 -03:00
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 08:46:55 -03:00
[[nodiscard]] CSSPixelSize solve_replaced_size_constraint(CSSPixels input_width, CSSPixels input_height, Box const&, AvailableSpace const&) const;
LibWeb: Make solve_replaced_size_constraint() into FormattingContext
2023-05-31 05:41:32 -03: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 11:51:24 -03:00
ShrinkToFitResult calculate_shrink_to_fit_widths(Box const&);
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03: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 10:29:17 -03:00
void layout_absolutely_positioned_element(Box const&, AvailableSpace const&);
void compute_width_for_absolutely_positioned_element(Box const&, AvailableSpace const&);
void compute_width_for_absolutely_positioned_non_replaced_element(Box const&, AvailableSpace const&);
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 12:47:50 -03:00
void compute_width_for_absolutely_positioned_replaced_element(Box const&, AvailableSpace const&);
LibWeb: Fix abspos flex container with height:auto getting zero height When laying out abspos boxes, we compute the height twice: before and after the inside of the box has been laid out. The first pass allows percentage vertical values inside the box to be resolved against the box's height. The second pass resolves the final used value for the height of the box itself. In cases where the box height depends on the results of inside layout, we were incorrectly setting the box to having a definite zero height. This led to incorrect results when sizing an abspos flex container, since the FFC sizes containers (in row layouts) based on whether the container has a definite height. To avoid this problem, this patch adds an enum so we can differentiate between the two abspos height computation passes. If the first pass discovers a dependency on the inside layout, we simply bail out of computing the height, leaving it as indefinite. This allows the FFC to size its container correctly, and the correct height gets set by the second pass.
2023-01-06 17:05:18 -03:00
enum class BeforeOrAfterInsideLayout {
Before,
After,
};
void compute_height_for_absolutely_positioned_element(Box const&, AvailableSpace const&, BeforeOrAfterInsideLayout);
void compute_height_for_absolutely_positioned_non_replaced_element(Box const&, AvailableSpace const&, BeforeOrAfterInsideLayout);
LibWeb: Obey CSS aspect-ratio property during layout Calculate a "preferred aspect ratio" based on the value of `aspect-ratio` and the presence of a natural aspect ratio, and use that in layout. This is by no means complete or perfect, but we do now apply the given aspect-ratio to things. The spec is a bit vague, just saying to calculate sizes for aspect-ratio'ed boxes the same as you would for replaced elements. My naive solution here is to find everywhere we were checking for a ReplacedBox, and then also accept a regular Box with a preferred aspect ratio. This gets us pretty far. :^) https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all implemented.
2023-06-08 12:47:50 -03:00
void compute_height_for_absolutely_positioned_replaced_element(Box const&, AvailableSpace const&, BeforeOrAfterInsideLayout);
LibWeb: Move absolute positioning up to FormattingContext It seems like both BFC and IFC can have absolutely positioned children. It's a bit strange, but consider the following HTML: <html><body>foobar<img style="position: absolute"></body></html> In such a document, the <img> element is an absolutely positioned child of a block-level element (<body>) with no block-level children. An IFC is established for <body>, and needs to handle layout for <img>.
2021-01-06 14:18:46 -03:00
LibWeb: Don't use BFC auto height for non-BFC abspos elements While CSS 2.2 does tell us to use the "auto height for BFC roots" calculation when resolving auto heights for abspos elements, that doesn't make sense for other formatting context roots, e.g flex. In lieu of implementing the entire new absolute positioning model from CSS-POSITION-3, this patch borrows one small nugget from it: using fit-content height as the auto height for non-BFC-root abspos elements.
2023-06-20 08:20:08 -03:00
[[nodiscard]] Optional<CSSPixels> compute_auto_height_for_absolutely_positioned_element(Box const&, AvailableSpace const&, BeforeOrAfterInsideLayout) const;
LibWeb: Derive box baseline from last child *with line boxes* Before this change, we always derived a box's baseline from its last child, even if the last child didn't have any line boxes inside. This caused baselines to slip further down vertically than expected. There are more baseline alignment issues to fix, but this one was responsible for a fair chunk of trouble. :^)
2023-07-25 05:58:11 -03:00
[[nodiscard]] Box const* box_child_to_derive_baseline_from(Box const&) const;
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
Type m_type {};
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
LayoutMode m_layout_mode;
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-14 20:25:12 -03:00
LibWeb: Keep track of the parent of each formatting context This will allow us to find the containing block formatting context when needed later on.
2020-11-25 16:08:52 -03:00
FormattingContext* m_parent { nullptr };
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-14 12:01:23 -03:00
GC::Ref<Box const> m_context_box;
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 16:13:47 -03:00
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03:00
LayoutState& m_state;
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
};
}
Reference in a new issue Copy permalink