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

157 lines
6.8 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 13:38:18 +01:00
/*
LibWeb: Add Layout::FormattingState The purpose of this new object will be to keep track of various states during an ongoing layout. Until now, we've been updating layout tree nodes as we go during layout, which adds an invisible layer of implicit serialization to the whole layout system. My idea with FormattingState is that running layout will produce a result entirely contained within the FormattingState object. At the end of layout, it can then be applied to the layout tree, or simply queried for some metrics we were trying to determine. When doing subtree layouts to determine intrinsic sizes, we will eventually be able to clone the current FormattingState, and run the subtree layout in isolation, opening up opportunities for parallelism. This first patch doesn't go very far though, it merely adds the object as a skeleton class, and makes sure the root BFC has one. :^)
2022-02-19 20:13:47 +01:00
* Copyright (c) 2020-2022, Andreas Kling <kling@serenityos.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 13:38:18 +01:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 13:38:18 +01:00
*/
#pragma once
LibWeb: Add missing headers
2021-10-10 15:56:29 +02: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 13:38:18 +01: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 19:12:09 +02: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 23:30:32 +02: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 13:38:18 +01:00
namespace Web::Layout {
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 18:24:07 +02: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-15 01:25:12 +02: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 15:19:32 +01: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-15 01:25:12 +02: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 10:32:23 +02: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-15 01:25:12 +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
virtual void run(Box const&, LayoutMode, AvailableSpace const&) = 0;
// 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 09:57:31 +01: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 13:38:18 +01: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 13:39:43 +02: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 17:46:10 +00: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 13:39:43 +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
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 13:38:18 +01: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 20:08:52 +01:00
FormattingContext* parent() { return m_parent; }
Everywhere: Run clang-format
2022-04-01 20: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 20:08:52 +01: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-15 01:25:12 +02:00
Type type() const { return m_type; }
bool is_block_formatting_context() const { return type() == Type::Block; }
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 12:19:42 +01: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 20:10:39 +01: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 10:32:23 +02:00
[[nodiscard]] static Optional<Type> formatting_context_type_created_by_box(Box const&);
Everywhere: Run clang-format
2022-04-01 20: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 20:10:39 +01: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 16:47:50 +01: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 22:27:09 +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
OwnPtr<FormattingContext> create_independent_formatting_context_if_needed(LayoutState&, 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 18:24:07 +02: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 19:54:09 +01: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 17:46:10 +00:00
CSSPixels calculate_min_content_width(Layout::Box const&) const;
CSSPixels calculate_max_content_width(Layout::Box const&) const;
CSSPixels calculate_min_content_height(Layout::Box const&, AvailableSize const& available_width) const;
CSSPixels calculate_max_content_height(Layout::Box const&, AvailableSize const& available_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 14:36:59 +01:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00: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 14:36:59 +01:00
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 22:17:24 +03:00
CSS::Length calculate_inner_width(Layout::Box const&, AvailableSize const&, CSS::Size const& width) const;
CSS::Length calculate_inner_height(Layout::Box const&, AvailableSize const&, CSS::Size const& height) const;
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 09:57:31 +01: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 14:44:36 +01: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 10:18:34 +02:00
[[nodiscard]] CSSPixelRect absolute_content_rect(Box const&) const;
[[nodiscard]] CSSPixelRect margin_box_rect(Box const&) const;
[[nodiscard]] CSSPixelRect margin_box_rect_in_ancestor_coordinate_space(Box const&, Box const& ancestor_box) const;
[[nodiscard]] CSSPixelRect border_box_rect(Box const&) const;
[[nodiscard]] CSSPixelRect border_box_rect_in_ancestor_coordinate_space(Box const&, Box const& ancestor_box) const;
[[nodiscard]] CSSPixelRect content_box_rect(Box const&) const;
[[nodiscard]] CSSPixelRect content_box_rect_in_ancestor_coordinate_space(Box const&, Box const& ancestor_box) const;
[[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: Remove unnecessary static formatting context functions At one point in the past, we had some functions that were called across different formatting context types, which necessitated making them static and taking the LayoutState as a parameter. In all cases, those functions were used to do incorrect hacks, all of which we've replaced with more correct solutions. :^)
2023-05-31 09:28:03 +02:00
[[nodiscard]] CSSPixels containing_block_width_for(Box const&) const;
[[nodiscard]] CSSPixels containing_block_height_for(Box 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 15:17:47 +02:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00: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 15:29:17 +02:00
virtual bool can_determine_size_of_child() const { return false; }
virtual void determine_width_of_child(Box const&, AvailableSpace const&) { }
virtual void determine_height_of_child(Box const&, AvailableSpace const&) { }
LibWeb: Add a helper for calculating the stretch-fit width of a box
2022-09-26 15:41:22 +02:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
virtual CSSPixelPoint calculate_static_position(Box const&) const;
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 10:11:54 +01: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 13:48:28 +02:00
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 13:38:18 +01:00
protected:
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
FormattingContext(Type, 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 13:38:18 +01:00
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 18:44:40 +01:00
static bool should_treat_width_as_auto(Box const&, AvailableSpace const&);
static bool should_treat_height_as_auto(Box const&, AvailableSpace 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 15:29:17 +02:00
OwnPtr<FormattingContext> layout_inside(Box const&, LayoutMode, AvailableSpace const&);
LibWeb: Rename FormattingContext::compute_position() => compute_inset() This function computes the used inset properties, not the position of a box per se, so let's call it something more accurate.
2022-03-27 15:35:28 +02:00
void compute_inset(Box const& 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 13:38:18 +01: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 14:44:36 +01: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 17:46:10 +00: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 12:30:30 +01: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 13:37:15 +00: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;
};
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 13:38:18 +01:00
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 17:46:10 +00: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 13:38:18 +01: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 16:47:50 +01: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 14:45:52 +01: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-12 00:20:31 +01: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 16:47:50 +01:00
[[nodiscard]] CSSPixelSize solve_replaced_size_constraint(CSSPixels input_width, CSSPixels input_height, Box const&) const;
LibWeb: Make solve_replaced_size_constraint() into FormattingContext
2023-05-31 10:41:32 +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
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 13:38:18 +01: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
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 16:47:50 +01: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 21:05:18 +01: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 16:47:50 +01: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 18:18:46 +01: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-15 01:25:12 +02:00
Type m_type {};
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 20:08:52 +01:00
FormattingContext* m_parent { nullptr };
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
JS::NonnullGCPtr<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 20:13:47 +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
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 13:38:18 +01: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 16:47:50 +01:00
bool box_is_sized_as_replaced_element(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 13:38:18 +01:00
}
Reference in a new issue Copy permalink