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

56 lines
1.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 09:38:18 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020-2024, Andreas Kling <andreas@ladybird.org>
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Reorganize layout system in terms of formatting contexts This is a first (huge) step towards modernizing the layout architecture and bringing it closer to spec language. Layout is now performed by a stack of formatting contexts, operating on the box tree (or layout tree, if you will.) There are currently three types of formatting context: - BlockFormattingContext (BFC) - InlineFormattingContext (IFC) - TableFormattingContext (TFC) Document::layout() creates the initial BlockFormattingContext (BFC) which lays out the initial containing block (ICB), and then we recurse through the tree, creating BFC, IFC or TFC as appropriate and handing over control at the context boundaries. The majority of this patch is just refactoring the old logic spread out in LayoutBlock and LayoutTableRowGroup, and turning into these context classes instead. A lot more cleanup will be needed. There are many architectural wins here, the main one being that layout is no longer performed by boxes themselves, which gives us much greater flexibility in the outer/inner layout of a given box.
2020-11-22 09:38:18 -03:00
*/
#pragma once
LibWeb: Pass current target box to BFC::run() The BFC "context box" is now the outer box of the block formatting context. Previously the context box was always the current target box, which made it hard to reason about who was really the containing block of whom in various places. Note that IFC still has the containing block as its context box, this change only affects BFC. However, to clarify the situation in IFC, I've added a containing_block() getter than returns the context_box().
2020-12-06 15:48:02 -03:00
#include <AK/Types.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: Move line boxes from Layout::Box to BlockContainer Per the spec, only a BlockContainer" can have line boxes, so let's not clutter up every Layout::Box with line boxes. This also allows us to establish an invariant that BFC and IFC always operate on a Layout::BlockContainer. Note that if BlockContainer has all block-level children, its line boxes are not used for anything. They are only used in the all inline-level children scenario.
2021-10-06 16:53:25 -03:00
#include <LibWeb/Layout/BlockContainer.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/Layout/FormattingContext.h>
namespace Web::Layout {
class InlineFormattingContext final : public FormattingContext {
public:
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
InlineFormattingContext(LayoutState&, LayoutMode, BlockContainer const& containing_block, LayoutState::UsedValues& containing_block_used_values, BlockFormattingContext& parent);
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
~InlineFormattingContext();
LibWeb: Make IFC aware that its parent is always a BFC This simplifies some code and allows us to use tighter types for the parent context everywhere.
2022-01-23 11:22:18 -03:00
BlockFormattingContext& parent();
BlockFormattingContext const& parent() const;
LibWeb: Move line boxes from Layout::Box to BlockContainer Per the spec, only a BlockContainer" can have line boxes, so let's not clutter up every Layout::Box with line boxes. This also allows us to establish an invariant that BFC and IFC always operate on a Layout::BlockContainer. Note that if BlockContainer has all block-level children, its line boxes are not used for anything. They are only used in the all inline-level children scenario.
2021-10-06 16:53:25 -03:00
BlockContainer const& containing_block() const { return static_cast<BlockContainer const&>(context_box()); }
LibWeb: Pass current target box to BFC::run() The BFC "context box" is now the outer box of the block formatting context. Previously the context box was always the current target box, which made it hard to reason about who was really the containing block of whom in various places. Note that IFC still has the containing block as its context box, this change only affects BFC. However, to clarify the situation in IFC, I've added a containing_block() getter than returns the context_box().
2020-12-06 15:48:02 -03:00
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
virtual void run(AvailableSpace const&) override;
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 14:46:10 -03:00
virtual CSSPixels automatic_content_height() const override;
virtual CSSPixels automatic_content_width() const override;
LibWeb: Define static position calculation separately for each FC Static position of a box is defined by formatting context type it belongs to, so let's define this algorithm separately for each FC instead of assuming FormattingContext::calculate_static_position_rect() understands how to handle all of them. Also with this change calculate_static_position_rect() is no longer virtual function.
2024-10-05 17:18:53 -03:00
StaticPositionRect calculate_static_position_rect(Box const&) 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 dimension_box_on_line(Box const&, LayoutMode);
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 11:07:19 -03:00
LibWeb: Make inline layout independent of direction This patch separates the notion of x, y, width, and height, from inline_offset, block_offset, inline_length, and block_length. These can then be used to compute the final screen positions, in respect of the desired layout direction. This is the terminology used in https://drafts.csswg.org/css-writing-modes/#text-flow This makes it possible to use this layout algorithm to flow text in any direction. For example, vertically.
2024-10-29 08:32:59 -03:00
CSSPixels leftmost_inline_offset_at(CSSPixels y) const;
LibWeb: Replace to_px() with to_px_or_zero() in InlineFormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 13:30:18 -03:00
AvailableSize available_space_for_line(CSSPixels y) const;
LibWeb: Make inline layout independent of direction This patch separates the notion of x, y, width, and height, from inline_offset, block_offset, inline_length, and block_length. These can then be used to compute the final screen positions, in respect of the desired layout direction. This is the terminology used in https://drafts.csswg.org/css-writing-modes/#text-flow This makes it possible to use this layout algorithm to flow text in any direction. For example, vertically.
2024-10-29 08:32:59 -03:00
bool any_floats_intrude_at_block_offset(CSSPixels block_offset) const;
bool can_fit_new_line_at_block_offset(CSSPixels block_offset) const;
LibWeb: Move available_space_for_line() into InlineFormattingContext
2022-01-18 07:00:25 -03:00
LibWeb: Better handling of floating boxes from inline formatting context Handle the clear property for floating boxes and add tracking for vertical clearence within an inline formatting context.
2023-07-29 01:05:45 -03:00
CSSPixels vertical_float_clearance() const;
void set_vertical_float_clearance(CSSPixels);
LibWeb: Use LineBuilder in IFC to layout line boxes incrementally This resolves a long-standing architectural problem in LibWeb that made it unable to place CSS floating objects correctly due to not having final vertical position information when computing the amount of available horizontal space for each line.
2022-01-19 07:59:44 -03:00
private:
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-10 20:03:02 -03:00
void generate_line_boxes();
LibWeb: Make sure we always apply size constraints in IFC Pre-compute the effective containing block width in the IFC constructor and use that throughout.
2022-07-09 15:56:59 -03:00
void apply_justification_to_fragments(CSS::TextJustify, LineBox&, bool is_last_line);
LibWeb: Cache a pointer to the containing block state in IFC
2022-07-09 15:45:55 -03:00
LibWeb: Use cached UsedValues pointer in IFC and its helper classes This avoids expensive LayoutState lookups when we already have the pointer sitting around anyway.
2024-03-15 15:25:00 -03:00
LayoutState::UsedValues& m_containing_block_used_values;
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 10:29:17 -03:00
Optional<AvailableSpace> m_available_space;
LibWeb: Convert InlineFormattingContext to new pixel units
2022-11-03 14:48:46 -03:00
CSSPixels m_automatic_content_width { 0 };
CSSPixels m_automatic_content_height { 0 };
LibWeb: Better handling of floating boxes from inline formatting context Handle the clear property for floating boxes and add tracking for vertical clearence within an inline formatting context.
2023-07-29 01:05:45 -03:00
CSSPixels m_vertical_float_clearance { 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
};
}
Reference in a new issue Copy permalink