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

113 lines
4.2 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
/*
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
* 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 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: 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 {
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,
Table,
SVG,
};
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
virtual void run(Box const&, LayoutMode) = 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.
virtual float automatic_content_height() const = 0;
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 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; }
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 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
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: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03:00
static float compute_width_for_replaced_element(LayoutState const&, ReplacedBox const&);
static float compute_height_for_replaced_element(LayoutState const&, ReplacedBox 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: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03: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 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: Make separate functions for calculating min/max content sizes At first, these are just wrappers around calculate_intrinsic_sizes(). Eventually, we'll make them do only the work necessary for their specific size.
2022-07-07 19:40:53 -03:00
float calculate_min_content_width(Layout::Box const&) const;
float calculate_max_content_width(Layout::Box const&) const;
float calculate_min_content_height(Layout::Box const&) const;
float calculate_max_content_height(Layout::Box 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: Take size constraints into account in fit-content calculations Also avoid calculating both min-content and max-content sizes when only one of them is needed.
2022-07-20 12:59:46 -03:00
float calculate_fit_content_height(Layout::Box const&, SizeConstraint, Optional<float> available_height) const;
float calculate_fit_content_width(Layout::Box const&, SizeConstraint, Optional<float> 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 10:36:59 -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
virtual float greatest_child_width(Box 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
float containing_block_width_for(Box const& box) const { return containing_block_width_for(box, m_state); }
float containing_block_height_for(Box const& box) const { return containing_block_height_for(box, m_state); }
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03:00
static float containing_block_width_for(Box const&, LayoutState const&);
static float containing_block_height_for(Box const&, LayoutState 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: Rename IntrinsicSizeDetermination to IntrinsicSizing This matches the exact terminology used in CSS-SIZING-3: https://drafts.csswg.org/css-sizing-3/#intrinsic-sizing
2022-07-20 13:12:12 -03:00
virtual void run_intrinsic_sizing(Box const&);
LibWeb: More specialization of intrinsic sizing layout This patch adds a separate entry point for this kind of layout. We override it in BFC to set up initial width/height values for the BFC root block. Resulting dimensions are assigned as content_width and content_height at the end of intrinsic sizing, for each axis, if it's either "auto" or there's a min-content or max-content constraint in effect.
2022-07-10 17:06:20 -03:00
LibWeb: Factor out compute_y_position Factor out the code that computes the vertical position of a Box with respect to its siblings so that it can be used when computing the absolutely positioned divs as well.
2022-08-10 14:19:44 -03:00
float compute_box_y_position_with_respect_to_siblings(Box const&, LayoutState::UsedValues 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
protected:
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03: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 09:38:18 -03:00
LibWeb: Take size constraints into account in fit-content calculations Also avoid calculating both min-content and max-content sizes when only one of them is needed.
2022-07-20 12:59:46 -03:00
float calculate_fit_content_size(float min_content_size, float max_content_size, SizeConstraint, Optional<float> available_space) 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: 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
OwnPtr<FormattingContext> layout_inside(Box const&, LayoutMode);
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 10:35:28 -03: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 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: 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
float left { 0 };
float right { 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
struct ShrinkToFitResult {
float preferred_width { 0 };
float preferred_minimum_width { 0 };
};
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 18:30:32 -03:00
static float tentative_width_for_replaced_element(LayoutState const&, ReplacedBox const&, CSS::LengthPercentage const& computed_width);
static float tentative_height_for_replaced_element(LayoutState const&, ReplacedBox const&, CSS::LengthPercentage const& computed_height);
static float compute_auto_height_for_block_formatting_context_root(LayoutState const&, BlockContainer const&);
static float compute_auto_height_for_block_level_element(LayoutState const&, Box 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: 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: 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
void layout_absolutely_positioned_element(Box const&);
void compute_width_for_absolutely_positioned_element(Box const&);
void compute_width_for_absolutely_positioned_non_replaced_element(Box const&);
void compute_width_for_absolutely_positioned_replaced_element(ReplacedBox const&);
void compute_height_for_absolutely_positioned_element(Box const&);
void compute_height_for_absolutely_positioned_non_replaced_element(Box const&);
void compute_height_for_absolutely_positioned_replaced_element(ReplacedBox const&);
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: 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: 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 };
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& 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