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.cpp

2077 lines
97 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
*/
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
#include <LibWeb/Dump.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/Layout/BlockFormattingContext.h>
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
#include <LibWeb/Layout/Box.h>
LibWeb: Add a very naive Layout::FlexFormattingContext :^) This is very dumb and only lays out its child boxes on a horizontal line with their shrink-to-fit widths. You have to start somewhere! :^)
2021-01-18 17:33:46 +01:00
#include <LibWeb/Layout/FlexFormattingContext.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/Layout/FormattingContext.h>
LibWeb: Add GridFormattingContext
2022-08-23 10:36:27 +02:00
#include <LibWeb/Layout/GridFormattingContext.h>
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
#include <LibWeb/Layout/ReplacedBox.h>
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02:00
#include <LibWeb/Layout/SVGFormattingContext.h>
#include <LibWeb/Layout/SVGSVGBox.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/Layout/TableFormattingContext.h>
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
#include <LibWeb/Layout/Viewport.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 {
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-11 01:03:02 +02:00
FormattingContext::FormattingContext(Type type, LayoutMode layout_mode, LayoutState& state, Box const& context_box, FormattingContext* parent)
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
: m_type(type)
LibWeb: Save layout mode inside formatting context object FormattingContext::run() does not allow reentrancy, so it's safe to save and access layout mode from FC object. This avoids need to drill it through methods of a formatting context and makes it clear that this value could never be changed after FC construction.
2024-09-11 01:03:02 +02:00
, m_layout_mode(layout_mode)
LibWeb: Expose FormattingContext type Instead of having a virtual is_block_formatting_context(), let's have a type() that can tell you exactly which type of formatting context it is.
2021-10-15 01:25:12 +02:00
, m_parent(parent)
LibWeb: Convert const pointer to nonnull into a reference
2021-10-15 23:15:12 +02:00
, m_context_box(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
, m_state(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
{
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 13:21:51 -06:00
FormattingContext::~FormattingContext() = default;
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: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Block_formatting_context
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
bool FormattingContext::creates_block_formatting_context(Box const& box)
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: Make sure replaced elements never create a BFC
2022-10-06 17:29:05 +02:00
// NOTE: Replaced elements never create a BFC.
if (box.is_replaced_box())
return false;
LibWeb: Flex, grid and table containers should not create BFC Fixes https://github.com/SerenityOS/serenity/issues/16082
2022-11-25 06:44:33 +03:00
// display: table
if (box.display().is_table_inside()) {
return false;
}
// display: flex
if (box.display().is_flex_inside()) {
return false;
}
// display: grid
if (box.display().is_grid_inside()) {
return false;
}
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// NOTE: This function uses MDN as a reference, not because it's authoritative,
// but because they've gathered all the conditions in one convenient location.
// The root element of the document (<html>).
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
if (box.is_root_element())
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Floats (elements where float isn't none).
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
if (box.is_floating())
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Absolutely positioned elements (elements where position is absolute or fixed).
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
if (box.is_absolutely_positioned())
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Inline-blocks (elements with display: inline-block).
if (box.display().is_inline_block())
return true;
// Table cells (elements with display: table-cell, which is the default for HTML table cells).
if (box.display().is_table_cell())
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
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Table captions (elements with display: table-caption, which is the default for HTML table captions).
if (box.display().is_table_caption())
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
return true;
LibWeb: Add a very naive Layout::FlexFormattingContext :^) This is very dumb and only lays out its child boxes on a horizontal line with their shrink-to-fit widths. You have to start somewhere! :^)
2021-01-18 17:33:46 +01:00
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// FIXME: Anonymous table cells implicitly created by the elements with display: table, table-row, table-row-group, table-header-group, table-footer-group
// (which is the default for HTML tables, table rows, table bodies, table headers, and table footers, respectively), or inline-table.
// Block elements where overflow has a value other than visible and clip.
LibWeb: Create a new BFC when the overflow is neither visible nor clip From MDN, a block overflow context should be created for "Block elements where overflow has a value other than visible and clip."
2021-03-30 16:04:32 -04:00
CSS::Overflow overflow_x = box.computed_values().overflow_x();
if ((overflow_x != CSS::Overflow::Visible) && (overflow_x != CSS::Overflow::Clip))
return true;
CSS::Overflow overflow_y = box.computed_values().overflow_y();
if ((overflow_y != CSS::Overflow::Visible) && (overflow_y != CSS::Overflow::Clip))
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// display: flow-root.
if (box.display().is_flow_root_inside())
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02:00
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// FIXME: Elements with contain: layout, content, or paint.
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02:00
if (box.parent()) {
LibWeb: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
auto parent_display = box.parent()->display();
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Flex items (direct children of the element with display: flex or inline-flex) if they are neither flex nor grid nor table containers themselves.
LibWeb: Flex, grid and table containers should not create BFC Fixes https://github.com/SerenityOS/serenity/issues/16082
2022-11-25 06:44:33 +03:00
if (parent_display.is_flex_inside())
return true;
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// Grid items (direct children of the element with display: grid or inline-grid) if they are neither flex nor grid nor table containers themselves.
LibWeb: Flex, grid and table containers should not create BFC Fixes https://github.com/SerenityOS/serenity/issues/16082
2022-11-25 06:44:33 +03:00
if (parent_display.is_grid_inside())
return true;
LibWeb: Add a very naive Layout::FlexFormattingContext :^) This is very dumb and only lays out its child boxes on a horizontal line with their shrink-to-fit widths. You have to start somewhere! :^)
2021-01-18 17:33:46 +01:00
}
LibWeb: Tidy up FormattingContext::creates_block_formatting_context() We use comments from MDN here, since the rules for creating a BFC are inconsistently spread across many different specifications.
2022-10-06 16:51:53 +02:00
// FIXME: Multicol containers (elements where column-count or column-width isn't auto, including elements with column-count: 1).
// FIXME: column-span: all should always create a new formatting context, even when the column-span: all element isn't contained by a multicol container (Spec change, Chrome bug).
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
return false;
}
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
Optional<FormattingContext::Type> FormattingContext::formatting_context_type_created_by_box(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: 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
if (box.is_replaced_box() && !box.can_have_children()) {
return Type::InternalReplaced;
LibWeb: Create a no-op formatting context for childless replaced boxes This is a hack that allows block-level replaced elements to be flex items. Flexbox layout currently assumes (in many places) that it's always possible to create an independent formatting context for each of its items.
2022-04-11 00:39:43 +02: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
if (!box.can_have_children())
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
return {};
LibWeb: Add SVGFormattingContext to handle SVG box trees Instead of trying to layout SVG boxes as if they are regular CSS boxes, let's invent an "SVG formatting context" and let it manage SVG boxes. To facilitate this, Layout::SVGBox no longer inherits from ReplacedBox, and is instead a simple, "inline-block" style BlockBox.
2021-09-17 23:12:16 +02: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
if (is<SVGSVGBox>(box))
return Type::SVG;
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02: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
auto display = box.display();
LibWeb: Proritize FlexFormattingContext when display: flex is specified An item with display: flex and overflow: hidden would've caused a BlockFormattingContext before.
2021-09-23 14:24:04 +02: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
if (display.is_flex_inside())
return Type::Flex;
LibWeb: Add a very naive Layout::FlexFormattingContext :^) This is very dumb and only lays out its child boxes on a horizontal line with their shrink-to-fit widths. You have to start somewhere! :^)
2021-01-18 17:33:46 +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
if (display.is_table_inside())
return Type::Table;
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02: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
if (display.is_grid_inside())
return Type::Grid;
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02: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
if (creates_block_formatting_context(box))
return Type::Block;
LibWeb: Add GridFormattingContext
2022-08-23 10:36:27 +02: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
if (box.children_are_inline())
LibWeb: Check if block creates BFC even if all it's children are inline Even if block has all children inline there need to be a check if it creates BFC because otherwise IFC will be looking in wrong parent BFC to calculate space used by floats.
2022-12-11 01:27:42 +03:00
return {};
LibWeb: Start work towards modern CSS "display" values Until now, we've internally thought of the CSS "display" property as a single-value property. In practice, "display" is a much more complex property that comes in a number of configurations. The most interesting one is the two-part format that describes the outside and inside behavior of a box. Switching our own internal representation towards this model will allow for much cleaner abstractions around layout and the various formatting contexts. Note that we don't *parse* two-part "display" yet, this is only about changing the internal representation of the property. Spec: https://drafts.csswg.org/css-display
2021-10-06 17:57:44 +02: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
// The box is a block container that doesn't create its own BFC.
// It will be formatted by the containing BFC.
if (!display.is_flow_inside()) {
LibWeb: Add hack to avoid crashing on !child_display.is_flow_inside() When encountering a box that claims to have block-level children, but its CSS display type isn't actually "flow" inside, we would previously crash due to a VERIFY() failure. However, many sites choke on this due to freestanding table-related boxes like those created by "table-row" and "table-row-group". We're supposed to fix those up by wrapping them in a full set of table boxes during layout tree construction, but that algorithm obviously isn't working correctly in all cases. So let's work around the crashes for now, allowing many more sites to load (even if visually incorrect.) This is a rather monstrous hack, and we should get rid of it as soon as it's not needed anymore.
2022-02-21 16:53:38 +01:00
// HACK: Instead of crashing, create a dummy formatting context that does nothing.
// FIXME: Remove this once it's no longer needed. It currently swallows problem with standalone
// table-related boxes that don't get fixed up by CSS anonymous table box generation.
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
return Type::InternalDummy;
LibWeb: Add hack to avoid crashing on !child_display.is_flow_inside() When encountering a box that claims to have block-level children, but its CSS display type isn't actually "flow" inside, we would previously crash due to a VERIFY() failure. However, many sites choke on this due to freestanding table-related boxes like those created by "table-row" and "table-row-group". We're supposed to fix those up by wrapping them in a full set of table boxes during layout tree construction, but that algorithm obviously isn't working correctly in all cases. So let's work around the crashes for now, allowing many more sites to load (even if visually incorrect.) This is a rather monstrous hack, and we should get rid of it as soon as it's not needed anymore.
2022-02-21 16:53:38 +01:00
}
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
return {};
}
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
// FIXME: This is a hack. Get rid of it.
struct ReplacedFormattingContext : public FormattingContext {
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-11 01:03:02 +02:00
ReplacedFormattingContext(LayoutState& state, LayoutMode layout_mode, Box const& box)
: FormattingContext(Type::Block, layout_mode, state, box)
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
{
}
virtual CSSPixels automatic_content_width() const override { return 0; }
virtual CSSPixels automatic_content_height() const override { return 0; }
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-11 01:03:02 +02:00
virtual void run(AvailableSpace const&) override { }
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
};
// FIXME: This is a hack. Get rid of it.
struct DummyFormattingContext : public FormattingContext {
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-11 01:03:02 +02:00
DummyFormattingContext(LayoutState& state, LayoutMode layout_mode, Box const& box)
: FormattingContext(Type::Block, layout_mode, state, box)
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
{
}
virtual CSSPixels automatic_content_width() const override { return 0; }
virtual CSSPixels automatic_content_height() const override { return 0; }
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-11 01:03:02 +02:00
virtual void run(AvailableSpace const&) override { }
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
};
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-11 01:03:02 +02:00
OwnPtr<FormattingContext> FormattingContext::create_independent_formatting_context_if_needed(LayoutState& state, LayoutMode layout_mode, Box const& child_box)
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
{
auto type = formatting_context_type_created_by_box(child_box);
if (!type.has_value())
return nullptr;
switch (type.value()) {
case Type::Block:
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-11 01:03:02 +02:00
return make<BlockFormattingContext>(state, layout_mode, verify_cast<BlockContainer>(child_box), this);
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
case Type::SVG:
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-11 01:03:02 +02:00
return make<SVGFormattingContext>(state, layout_mode, child_box, this);
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
case Type::Flex:
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-11 01:03:02 +02:00
return make<FlexFormattingContext>(state, layout_mode, child_box, this);
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
case Type::Grid:
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-11 01:03:02 +02:00
return make<GridFormattingContext>(state, layout_mode, child_box, this);
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
case Type::Table:
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-11 01:03:02 +02:00
return make<TableFormattingContext>(state, layout_mode, child_box, this);
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
case Type::InternalReplaced:
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-11 01:03:02 +02:00
return make<ReplacedFormattingContext>(state, layout_mode, child_box);
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
case Type::InternalDummy:
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-11 01:03:02 +02:00
return make<DummyFormattingContext>(state, layout_mode, child_box);
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
case Type::Inline:
// IFC should always be created by a parent BFC directly.
VERIFY_NOT_REACHED();
break;
default:
VERIFY_NOT_REACHED();
}
}
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> FormattingContext::layout_inside(Box const& child_box, LayoutMode layout_mode, AvailableSpace const& available_space)
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: Avoid some unnecessary inside layouts during intrinsic sizing When calculating intrinsic sizes, we don't need to recurse into *every* box and layout its insides. IIUC, we can skip any unconstrained box with definite sizes in both axes. So this patch does exactly that.
2022-07-20 18:13:11 +02:00
{
// OPTIMIZATION: If we're doing intrinsic sizing and `child_box` has definite size in both axes,
// we don't need to layout its insides. The size is resolvable without learning
// the metrics of whatever's inside the box.
auto const& used_values = m_state.get(child_box);
if (layout_mode == LayoutMode::IntrinsicSizing
&& used_values.width_constraint == SizeConstraint::None
&& used_values.height_constraint == SizeConstraint::None
&& used_values.has_definite_width()
&& used_values.has_definite_height()) {
return nullptr;
}
}
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
if (!child_box.can_have_children())
return {};
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-11 01:03:02 +02:00
auto independent_formatting_context = create_independent_formatting_context_if_needed(m_state, layout_mode, 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
if (independent_formatting_context)
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-11 01:03:02 +02:00
independent_formatting_context->run(available_space);
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
else
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-11 01:03:02 +02:00
run(available_space);
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
return independent_formatting_context;
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: 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
CSSPixels FormattingContext::greatest_child_width(Box const& 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: 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 max_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
if (box.children_are_inline()) {
LibWeb: Remove unnecessary verify_cast in greatest_child_width()
2022-10-06 17:28:00 +02:00
for (auto& line_box : m_state.get(box).line_boxes) {
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
max_width = max(max_width, line_box.width());
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
}
} else {
LibWeb: Don't include abspos children in containing block's auto width
2022-09-13 18:53:11 +02:00
box.for_each_child_of_type<Box>([&](Box const& child) {
if (!child.is_absolutely_positioned())
LibWeb: Return max margin box width from greatest_child_width Return max margin box width instead of max border box width from greatest_child_width. This change fixes: https://wpt.live/css/CSS2/margin-padding-clear/margin-008.xht
2022-11-23 22:15:24 +03:00
max_width = max(max_width, m_state.get(child).margin_box_width());
LibWeb: Use `IterationDecision` in single level Node iteration methods `Node::for_each_child()` and `Node::for_each_child_of_type()` callbacks now return an `IterationDecision`, which allows us to break early if required.
2024-05-04 14:59:52 +01:00
return IterationDecision::Continue;
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
});
}
return max_width;
}
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
FormattingContext::ShrinkToFitResult FormattingContext::calculate_shrink_to_fit_widths(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: Implement shrink-to-fit layout on top of intrinsic size cache Using the intrinsic size cache means we only perform the nested layout to determine intrinsic size *once* per root layout pass. Furthermore, by using a throwaway FormattingState, details of the nested layout can't leak into and mutate the outer layout.
2022-03-18 12:44:19 +01:00
return {
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-08 00:40:53 +02:00
.preferred_width = calculate_max_content_width(box),
.preferred_minimum_width = calculate_min_content_width(box),
LibWeb: Implement shrink-to-fit layout on top of intrinsic size cache Using the intrinsic size cache means we only perform the nested layout to determine intrinsic size *once* per root layout pass. Furthermore, by using a throwaway FormattingState, details of the nested layout can't leak into and mutate the outer layout.
2022-03-18 12:44:19 +01: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
}
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
CSSPixelSize FormattingContext::solve_replaced_size_constraint(CSSPixels input_width, CSSPixels input_height, Box const& box, AvailableSpace const& available_space) 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: 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
// 10.4 Minimum and maximum widths: 'min-width' and 'max-width'
LibWeb: Treat replaced size constraint resolutions as mutually exclusive Previously, we would run through all the constraints in the spec one by one, but if we check and resolve each constraint in the order they are defined in the spec, only the first four will ever match. This leads me to believe that these constraints are meant to be mutually exclusive instead, meaning that we must check the most specific constraints first and return upon the first resolution that matches.
2023-09-03 19:07:05 -05:00
// https://www.w3.org/TR/CSS22/visudet.html#min-max-widths
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: Fix spelling of non_anonymous_containing_block()
2023-06-14 15:31:40 +02:00
auto const& containing_block = *box.non_anonymous_containing_block();
LibWeb: Make solve_replaced_size_constraint() into FormattingContext
2023-05-31 10:41:32 +02:00
auto const& containing_block_state = m_state.get(containing_block);
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
auto width_of_containing_block = containing_block_state.content_width();
auto height_of_containing_block = containing_block_state.content_height();
LibWeb: Convert width/height and min-/max- versions to LengthPercentage A lot of this is quite ugly, but it should only be so until I remove Length::Type::Percentage entirely. (Which should happen later in this PR, otherwise, yell at me!) For now, a lot of things have to be resolved twice, first from a LengthPercentage to a Length, and then from a Length to a pixel one.
2022-01-19 16:19:43 +00:00
LibWeb: Treat replaced size constraint resolutions as mutually exclusive Previously, we would run through all the constraints in the spec one by one, but if we check and resolve each constraint in the order they are defined in the spec, only the first four will ever match. This leads me to believe that these constraints are meant to be mutually exclusive instead, meaning that we must check the most specific constraints first and return upon the first resolution that matches.
2023-09-03 19:07:05 -05:00
auto min_width = box.computed_values().min_width().is_auto() ? 0 : box.computed_values().min_width().to_px(box, width_of_containing_block);
auto specified_max_width = should_treat_max_width_as_none(box, available_space.width) ? input_width : box.computed_values().max_width().to_px(box, width_of_containing_block);
auto max_width = max(min_width, specified_max_width);
auto min_height = box.computed_values().min_height().is_auto() ? 0 : box.computed_values().min_height().to_px(box, height_of_containing_block);
auto specified_max_height = should_treat_max_height_as_none(box, available_space.height) ? input_height : box.computed_values().max_height().to_px(box, height_of_containing_block);
auto max_height = max(min_height, specified_max_height);
LibWeb: Resolve replaced element size constraints using aspect ratios Some replaced elements can have intrinsic aspect ratios but no intrinsic size. In these cases, the tentative sizes are undefined, and can therefore sometimes be zero. However, when resolving the size constraints, we are already guaranteed to have an intrinsic aspect ratio, so let's use that instead to calculate the resolved sizes.
2023-09-03 19:20:50 -05:00
CSSPixelFraction aspect_ratio = *box.preferred_aspect_ratio();
LibWeb: Treat replaced size constraint resolutions as mutually exclusive Previously, we would run through all the constraints in the spec one by one, but if we check and resolve each constraint in the order they are defined in the spec, only the first four will ever match. This leads me to believe that these constraints are meant to be mutually exclusive instead, meaning that we must check the most specific constraints first and return upon the first resolution that matches.
2023-09-03 19:07:05 -05:00
// These are from the "Constraint Violation" table in spec, but reordered so that each condition is
// interpreted as mutually exclusive to any other.
if (input_width < min_width && input_height > max_height)
return { min_width, max_height };
if (input_width > max_width && input_height < min_height)
return { max_width, min_height };
LibWeb: Fix division by zero in `solve_replaced_size_constraint()` Happened when input_width > 0 but input_height == 0. Fixes crashing on Discord that happens after clicking on direct messages conversation.
2024-04-23 13:16:44 +02:00
if (input_width > 0 && input_height > 0) {
LibWeb: Fix division by zero in `solve_replaced_size_constraint()` Fixes crashes that occur in Discord after clicking on a direct messages conversation.
2024-02-20 19:11:42 +01:00
if (input_width > max_width && input_height > max_height && max_width / input_width <= max_height / input_height)
return { max_width, max(min_height, max_width / aspect_ratio) };
if (input_width > max_width && input_height > max_height && max_width / input_width > max_height / input_height)
return { max(min_width, max_height * aspect_ratio), max_height };
if (input_width < min_width && input_height < min_height && min_width / input_width <= min_height / input_height)
return { min(max_width, min_height * aspect_ratio), min_height };
if (input_width < min_width && input_height < min_height && min_width / input_width > min_height / input_height)
return { min_width, min(max_height, min_width / aspect_ratio) };
}
LibWeb: Treat replaced size constraint resolutions as mutually exclusive Previously, we would run through all the constraints in the spec one by one, but if we check and resolve each constraint in the order they are defined in the spec, only the first four will ever match. This leads me to believe that these constraints are meant to be mutually exclusive instead, meaning that we must check the most specific constraints first and return upon the first resolution that matches.
2023-09-03 19:07:05 -05:00
if (input_width > max_width)
return { max_width, max(max_width / aspect_ratio, min_height) };
if (input_width < min_width)
return { min_width, min(min_width / aspect_ratio, max_height) };
if (input_height > max_height)
return { max(max_height * aspect_ratio, min_width), max_height };
if (input_height < min_height)
return { min(min_height * aspect_ratio, max_width), min_height };
return { input_width, input_height };
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: 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: Don't use BFC auto height for non-BFC abspos elements While CSS 2.2 does tell us to use the "auto height for BFC roots" calculation when resolving auto heights for abspos elements, that doesn't make sense for other formatting context roots, e.g flex. In lieu of implementing the entire new absolute positioning model from CSS-POSITION-3, this patch borrows one small nugget from it: using fit-content height as the auto height for non-BFC-root abspos elements.
2023-06-20 13:20:08 +02:00
Optional<CSSPixels> FormattingContext::compute_auto_height_for_absolutely_positioned_element(Box const& box, AvailableSpace const& available_space, BeforeOrAfterInsideLayout before_or_after_inside_layout) const
{
// NOTE: CSS 2.2 tells us to use the "auto height for block formatting context roots" here.
// That's fine as long as the box is a BFC root.
if (creates_block_formatting_context(box)) {
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return {};
return compute_auto_height_for_block_formatting_context_root(box);
}
// NOTE: For anything else, we use the fit-content height.
// This should eventually be replaced by the new absolute positioning model:
// https://www.w3.org/TR/css-position-3/#abspos-layout
LibWeb: Use inner available space to calculate auto height of abspos By using available_inner_space_or_constraints_from(available_space), we ensure that the available space used to calculate the min/max content height is constrained by the width specified for the box itself (I know that at least GFC always expects available width to be constrained by specified width if there is any). This change improves layout in "Recent news" block on https://telegram.org/
2023-11-14 17:33:45 +01:00
return calculate_fit_content_height(box, m_state.get(box).available_inner_space_or_constraints_from(available_space));
LibWeb: Don't use BFC auto height for non-BFC abspos elements While CSS 2.2 does tell us to use the "auto height for BFC roots" calculation when resolving auto heights for abspos elements, that doesn't make sense for other formatting context roots, e.g flex. In lieu of implementing the entire new absolute positioning model from CSS-POSITION-3, this patch borrows one small nugget from it: using fit-content height as the auto height for non-BFC-root abspos elements.
2023-06-20 13:20:08 +02:00
}
LibWeb: Handle height:auto separately for BFC root vs other block boxes I was wrong in 56df05ae446cd238af7234d004417ad72368b300, there are situations where floating children should not affect the auto height of their parent. It turns out we were using the "height:auto for BFC roots" algorithm for all height:auto blocks. This patch fixes that by splitting it into two separate functions, and implementing most of the two different variants. Note that we don't support vertical margin collapsing here yet. Thanks to Tim for noticing the error! :^)
2022-03-01 23:21:24 +01:00
// https://www.w3.org/TR/CSS22/visudet.html#root-height
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 FormattingContext::compute_auto_height_for_block_formatting_context_root(Box const& root) const
LibWeb: Handle height:auto separately for BFC root vs other block boxes I was wrong in 56df05ae446cd238af7234d004417ad72368b300, there are situations where floating children should not affect the auto height of their parent. It turns out we were using the "height:auto for BFC roots" algorithm for all height:auto blocks. This patch fixes that by splitting it into two separate functions, and implementing most of the two different variants. Note that we don't support vertical margin collapsing here yet. Thanks to Tim for noticing the error! :^)
2022-03-01 23:21:24 +01:00
{
// 10.6.7 'Auto' heights for block formatting context roots
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
Optional<CSSPixels> top;
Optional<CSSPixels> bottom;
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
LibWeb: Handle height:auto separately for BFC root vs other block boxes I was wrong in 56df05ae446cd238af7234d004417ad72368b300, there are situations where floating children should not affect the auto height of their parent. It turns out we were using the "height:auto for BFC roots" algorithm for all height:auto blocks. This patch fixes that by splitting it into two separate functions, and implementing most of the two different variants. Note that we don't support vertical margin collapsing here yet. Thanks to Tim for noticing the error! :^)
2022-03-01 23:21:24 +01:00
if (root.children_are_inline()) {
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
// If it only has inline-level children, the height is the distance between
LibWeb: Small fix to height computation for block-with-inline-children We now compute the used height of height:auto by measuring from the top content edge (y=0) to the bottom of the bottommost line box within the block container. This fixes an issue where we'd fail to account for the topmost line box being taller than any of its fragments (which can happen if the line-height is greater than the height of all fragments on the line.)
2021-10-28 19:17:23 +02:00
// the top content edge and the bottom of the bottommost line box.
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
auto const& line_boxes = m_state.get(root).line_boxes;
LibWeb: Small fix to height computation for block-with-inline-children We now compute the used height of height:auto by measuring from the top content edge (y=0) to the bottom of the bottommost line box within the block container. This fixes an issue where we'd fail to account for the topmost line box being taller than any of its fragments (which can happen if the line-height is greater than the height of all fragments on the line.)
2021-10-28 19:17:23 +02:00
top = 0;
LibWeb: Use correct top content edge when calculating auto block heights When the spec tells us to measure from the top content edge of a block, that just means we should measure from Y=0. We don't need to go looking for a child box with a negative top offset and measure from there.
2022-03-28 21:02:13 +02:00
if (!line_boxes.is_empty())
LibWeb: Store bottom edge location with each LineBox Previously we were computing the bottom edge of a line box by finding the bottommost fragment on the line. That method didn't give correct results for line boxes with no fragments (which is exactly what you get when inserting a bunch of <br> elements.) To cover all situations, we now keep track of the bottommost edge in the LineBox object itself.
2022-02-27 13:34:34 +01:00
bottom = line_boxes.last().bottom();
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
} else {
// If it has block-level children, the height is the distance between
// the top margin-edge of the topmost block-level child box
// and the bottom margin-edge of the bottommost block-level child box.
LibWeb: Handle height:auto separately for BFC root vs other block boxes I was wrong in 56df05ae446cd238af7234d004417ad72368b300, there are situations where floating children should not affect the auto height of their parent. It turns out we were using the "height:auto for BFC roots" algorithm for all height:auto blocks. This patch fixes that by splitting it into two separate functions, and implementing most of the two different variants. Note that we don't support vertical margin collapsing here yet. Thanks to Tim for noticing the error! :^)
2022-03-01 23:21:24 +01:00
root.for_each_child_of_type<Box>([&](Layout::Box& child_box) {
// Absolutely positioned children are ignored,
// and relatively positioned boxes are considered without their offset.
// Note that the child box may be an anonymous block box.
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
if (child_box.is_absolutely_positioned())
return IterationDecision::Continue;
LibWeb: Handle height:auto separately for BFC root vs other block boxes I was wrong in 56df05ae446cd238af7234d004417ad72368b300, there are situations where floating children should not affect the auto height of their parent. It turns out we were using the "height:auto for BFC roots" algorithm for all height:auto blocks. This patch fixes that by splitting it into two separate functions, and implementing most of the two different variants. Note that we don't support vertical margin collapsing here yet. Thanks to Tim for noticing the error! :^)
2022-03-01 23:21:24 +01:00
// FIXME: This doesn't look right.
if ((root.computed_values().overflow_y() == CSS::Overflow::Visible) && child_box.is_floating())
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
return IterationDecision::Continue;
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
auto const& child_box_state = m_state.get(child_box);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Convert 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 child_box_top = child_box_state.offset.y() - child_box_state.margin_box_top();
CSSPixels child_box_bottom = child_box_state.offset.y() + child_box_state.content_height() + child_box_state.margin_box_bottom();
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
if (!top.has_value() || child_box_top < top.value())
top = child_box_top;
if (!bottom.has_value() || child_box_bottom > bottom.value())
bottom = child_box_bottom;
return IterationDecision::Continue;
});
LibWeb: Include floats in height:auto for BFC root with inline children BFC roots with children_are_inline()==true can still have floating boxes as well. children_are_inline() is only concerned with in-flow children. For this reason, we have to always consider floats when calculating height:auto for BFC roots.
2022-03-26 00:11:37 +01:00
}
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
LibWeb: Include floats in height:auto for BFC root with inline children BFC roots with children_are_inline()==true can still have floating boxes as well. children_are_inline() is only concerned with in-flow children. For this reason, we have to always consider floats when calculating height:auto for BFC roots.
2022-03-26 00:11:37 +01:00
// In addition, if the element has any floating descendants
// whose bottom margin edge is below the element's bottom content edge,
// then the height is increased to include those edges.
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
for (auto floating_box : m_state.get(root).floating_descendants()) {
LibWeb: Account for float's container offsets in BFC root auto height When calculating the automatic height of a BFC root, we stretch it to contain the bottommost margin edge of floating boxes. Before this change, we assumed that floating boxes had coordinates relative to the BFC root, when they're actually relative to the floating box's containing block. This may or may not be the BFC root, so we have to use margin_box_in_ancestor_coordinate_space() to apply offsets from all boxes in the containing block chain (up to the BFC root).
2022-09-14 15:39:19 +02:00
// NOTE: Floating box coordinates are relative to their own containing block,
// which may or may not be the BFC root.
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
auto margin_box = margin_box_rect_in_ancestor_coordinate_space(*floating_box, root);
LibGfx+Everywhere: Change `Gfx::Rect` to be endpoint exclusive Previously, calling `.right()` on a `Gfx::Rect` would return the last column's coordinate still inside the rectangle, or `left + width - 1`. This is called 'endpoint inclusive' and does not make a lot of sense for `Gfx::Rect<float>` where a rectangle of width 5 at position (0, 0) would return 4 as its right side. This same problem exists for `.bottom()`. This changes `Gfx::Rect` to be endpoint exclusive, which gives us the nice property that `width = right - left` and `height = bottom - top`. It enables us to treat `Gfx::Rect<int>` and `Gfx::Rect<float>` exactly the same. All users of `Gfx::Rect` have been updated accordingly.
2023-05-22 00:41:18 +02:00
CSSPixels floating_box_bottom_margin_edge = margin_box.bottom();
LibWeb: Account for float's container offsets in BFC root auto height When calculating the automatic height of a BFC root, we stretch it to contain the bottommost margin edge of floating boxes. Before this change, we assumed that floating boxes had coordinates relative to the BFC root, when they're actually relative to the floating box's containing block. This may or may not be the BFC root, so we have to use margin_box_in_ancestor_coordinate_space() to apply offsets from all boxes in the containing block chain (up to the BFC root).
2022-09-14 15:39:19 +02:00
if (!bottom.has_value() || floating_box_bottom_margin_edge > bottom.value())
bottom = floating_box_bottom_margin_edge;
LibWeb: Include all floating descendants in BFC root's automatic height Before this change, we were only considering floating boxes that were immediate children of the BFC root.
2022-09-09 23:56:55 +02:00
}
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
return max(CSSPixels(0.0f), bottom.value_or(0) - top.value_or(0));
LibWeb: Fix height calculation for absolutely positioned boxes This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7) by including floating boxes into computation and implements one of the cases for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
2021-04-17 09:09:57 +03:00
}
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// 17.5.2 Table width algorithms: the 'table-layout' property
// https://www.w3.org/TR/CSS22/tables.html#width-layout
CSSPixels FormattingContext::compute_table_box_width_inside_table_wrapper(Box const& box, AvailableSpace const& available_space)
{
// Table wrapper width should be equal to width of table box it contains
auto const& computed_values = box.computed_values();
auto width_of_containing_block = available_space.width.to_px_or_zero();
auto zero_value = CSS::Length::make_px(0);
auto margin_left = computed_values.margin().left().resolved(box, width_of_containing_block);
auto margin_right = computed_values.margin().right().resolved(box, width_of_containing_block);
// If 'margin-left', or 'margin-right' are computed as 'auto', their used value is '0'.
if (margin_left.is_auto())
margin_left = zero_value;
if (margin_right.is_auto())
margin_right = zero_value;
// table-wrapper can't have borders or paddings but it might have margin taken from table-root.
auto available_width = width_of_containing_block - margin_left.to_px(box) - margin_right.to_px(box);
Optional<Box const&> table_box;
box.for_each_in_subtree_of_type<Box>([&](Box const& child_box) {
if (child_box.display().is_table_inside()) {
table_box = child_box;
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Break;
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
}
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Continue;
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
});
VERIFY(table_box.has_value());
LibWeb: Skip cells layout in table box width calculation There is no need to run full table layout if we are only interested in calculating its width. This change reduces compute_table_box_width_inside_table_wrapper() from ~30% to ~15% in profiles of "File changed" pages on github.
2024-03-19 10:18:49 +01:00
LayoutState throwaway_state(&m_state);
auto& table_box_state = throwaway_state.get_mutable(*table_box);
auto const& table_box_computed_values = table_box->computed_values();
table_box_state.border_left = table_box_computed_values.border_left().width;
table_box_state.border_right = table_box_computed_values.border_right().width;
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-11 01:03:02 +02:00
auto context = make<TableFormattingContext>(throwaway_state, LayoutMode::IntrinsicSizing, *table_box, this);
LibWeb: Remove `box` argument from FormattingContext::run() Root formatting context box is passed into constructor and saved in FC, so it's possible to access it from there instead of passing the same box into run().
2024-09-11 00:28:22 +02:00
context->run_until_width_calculation(m_state.get(*table_box).available_inner_space_or_constraints_from(available_space));
LibWeb: Skip cells layout in table box width calculation There is no need to run full table layout if we are only interested in calculating its width. This change reduces compute_table_box_width_inside_table_wrapper() from ~30% to ~15% in profiles of "File changed" pages on github.
2024-03-19 10:18:49 +01:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto table_used_width = throwaway_state.get(*table_box).border_box_width();
return available_space.width.is_definite() ? min(table_used_width, available_width) : table_used_width;
}
// 17.5.3 Table height algorithms
// https://www.w3.org/TR/CSS22/tables.html#height-layout
CSSPixels FormattingContext::compute_table_box_height_inside_table_wrapper(Box const& box, AvailableSpace const& available_space)
{
// Table wrapper height should be equal to height of table box it contains
auto const& computed_values = box.computed_values();
auto width_of_containing_block = available_space.width.to_px_or_zero();
auto height_of_containing_block = available_space.height.to_px_or_zero();
auto zero_value = CSS::Length::make_px(0);
auto margin_top = computed_values.margin().top().resolved(box, width_of_containing_block);
auto margin_bottom = computed_values.margin().bottom().resolved(box, width_of_containing_block);
// If 'margin-top', or 'margin-top' are computed as 'auto', their used value is '0'.
if (margin_top.is_auto())
margin_top = zero_value;
if (margin_bottom.is_auto())
margin_bottom = zero_value;
// table-wrapper can't have borders or paddings but it might have margin taken from table-root.
auto available_height = height_of_containing_block - margin_top.to_px(box) - margin_bottom.to_px(box);
LayoutState throwaway_state(&m_state);
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-11 01:03:02 +02:00
auto context = create_independent_formatting_context_if_needed(throwaway_state, LayoutMode::IntrinsicSizing, box);
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
VERIFY(context);
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-11 01:03:02 +02:00
context->run(m_state.get(box).available_inner_space_or_constraints_from(available_space));
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
Optional<Box const&> table_box;
box.for_each_in_subtree_of_type<Box>([&](Box const& child_box) {
if (child_box.display().is_table_inside()) {
table_box = child_box;
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Break;
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
}
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Continue;
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
});
VERIFY(table_box.has_value());
auto table_used_height = throwaway_state.get(*table_box).border_box_height();
return available_space.height.is_definite() ? min(table_used_height, available_height) : table_used_height;
}
LibWeb: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
// 10.3.2 Inline, replaced elements, https://www.w3.org/TR/CSS22/visudet.html#inline-replaced-width
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 FormattingContext::tentative_width_for_replaced_element(Box const& box, CSS::Size const& computed_width, AvailableSpace const& available_space) 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: Treat replaced % sizes as 0 if containing block is indefinite
2022-09-24 14:41:18 +02:00
// Treat percentages of indefinite containing block widths as 0 (the initial width).
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
if (computed_width.is_percentage() && !m_state.get(*box.containing_block()).has_definite_width())
LibWeb: Treat replaced % sizes as 0 if containing block is indefinite
2022-09-24 14:41:18 +02:00
return 0;
LibWeb: Treat unresolvable percentage sizes as auto on replaced elements For replaced elements with percentage width or height, we were treating them as 0 instead of auto when their containing block had an indefinite corresponding size. This produced incorrect layouts in various cases, and although I can't actually find something about this exact scenario in specs, the new behavior does match other browsers.
2022-11-03 18:46:50 +01:00
auto computed_height = should_treat_height_as_auto(box, available_space) ? CSS::Size::make_auto() : box.computed_values().height();
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: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
CSSPixels used_width = 0;
if (computed_width.is_auto()) {
used_width = computed_width.to_px(box, available_space.width.to_px_or_zero());
} else {
used_width = calculate_inner_width(box, available_space.width, computed_width);
}
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
// If 'height' and 'width' both have computed values of 'auto' and the element also has an intrinsic width,
// then that intrinsic width is the used value of 'width'.
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (computed_height.is_auto() && computed_width.is_auto() && box.has_natural_width())
return box.natural_width().value();
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
// If 'height' and 'width' both have computed values of 'auto' and the element has no intrinsic width,
// but does have an intrinsic height and intrinsic ratio;
// or if 'width' has a computed value of 'auto',
// 'height' has some other computed value, and the element does have an intrinsic ratio; then the used value of 'width' is:
//
// (used height) * (intrinsic ratio)
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
if ((computed_height.is_auto() && computed_width.is_auto() && !box.has_natural_width() && box.has_natural_height() && box.has_preferred_aspect_ratio())
|| (computed_width.is_auto() && !computed_height.is_auto() && box.has_preferred_aspect_ratio())) {
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
return compute_height_for_replaced_element(box, available_space) * box.preferred_aspect_ratio().value();
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: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
// If 'height' and 'width' both have computed values of 'auto' and the element has an intrinsic ratio but no intrinsic height or width,
// then the used value of 'width' is undefined in CSS 2.2. However, it is suggested that, if the containing block's width does not itself
// depend on the replaced element's width, then the used value of 'width' is calculated from the constraint equation used for block-level,
// non-replaced elements in normal flow.
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
if (computed_height.is_auto() && computed_width.is_auto() && !box.has_natural_width() && !box.has_natural_height() && box.has_preferred_aspect_ratio()) {
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
return calculate_stretch_fit_width(box, available_space.width);
LibWeb: Support <svg> elements with `display: block` There are a couple of things that went into this: - We now calculate the intrinsic width/height and aspect ratio of <svg> elements based on the spec algorithm instead of our previous ad-hoc guesswork solution. - Replaced elements with automatic size and intrinsic aspect ratio but no intrinsic dimensions are now sized with the stretch-fit width formula. - We take care to assign both used width and used height to <svg> elements before running their SVG formatting contexts. This ensures that the inside SVG content is laid out with knowledge of its viewport geometry. - We avoid infinite recursion in tentative_height_for_replaced_element() by using the already-calculated used width instead of calling the function that calculates the used width (since that may call us right back again).
2023-05-19 18:14:37 +02:00
}
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: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
// Otherwise, if 'width' has a computed value of 'auto', and the element has an intrinsic width, then that intrinsic width is the used value of 'width'.
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (computed_width.is_auto() && box.has_natural_width())
return box.natural_width().value();
LibWeb: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
// Otherwise, if 'width' has a computed value of 'auto', but none of the conditions above are met, then the used value of 'width' becomes 300px.
// If 300px is too wide to fit the device, UAs should use the width of the largest rectangle that has a 2:1 ratio and fits the device instead.
if (computed_width.is_auto())
return 300;
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
return used_width;
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
void FormattingContext::compute_width_for_absolutely_positioned_element(Box const& box, AvailableSpace const& available_space)
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: 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
if (box_is_sized_as_replaced_element(box))
compute_width_for_absolutely_positioned_replaced_element(box, available_space);
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
else
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
compute_width_for_absolutely_positioned_non_replaced_element(box, available_space);
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: 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
void FormattingContext::compute_height_for_absolutely_positioned_element(Box const& box, AvailableSpace const& available_space, BeforeOrAfterInsideLayout before_or_after_inside_layout)
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: 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
if (box_is_sized_as_replaced_element(box))
compute_height_for_absolutely_positioned_replaced_element(box, available_space, before_or_after_inside_layout);
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
else
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
compute_height_for_absolutely_positioned_non_replaced_element(box, available_space, before_or_after_inside_layout);
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: 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 FormattingContext::compute_width_for_replaced_element(Box const& box, AvailableSpace const& available_space) 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: 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
// 10.3.4 Block-level, replaced elements in normal flow...
// 10.3.2 Inline, replaced elements
auto zero_value = CSS::Length::make_px(0);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
auto width_of_containing_block = available_space.width.to_px_or_zero();
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: Treat unresolvable percentage sizes as auto on replaced elements For replaced elements with percentage width or height, we were treating them as 0 instead of auto when their containing block had an indefinite corresponding size. This produced incorrect layouts in various cases, and although I can't actually find something about this exact scenario in specs, the new behavior does match other browsers.
2022-11-03 18:46:50 +01:00
auto computed_width = should_treat_width_as_auto(box, available_space) ? CSS::Size::make_auto() : box.computed_values().width();
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
auto computed_height = should_treat_height_as_auto(box, available_space) ? CSS::Size::make_auto() : box.computed_values().height();
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
// 1. The tentative used width is calculated (without 'min-width' and 'max-width')
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
auto used_width = tentative_width_for_replaced_element(box, computed_width, available_space);
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
if (computed_width.is_auto() && computed_height.is_auto() && box.has_preferred_aspect_ratio()) {
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
CSSPixels w = used_width;
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
CSSPixels h = tentative_height_for_replaced_element(box, computed_height, available_space);
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
used_width = solve_replaced_size_constraint(w, h, box, available_space).width();
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
return used_width;
}
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
// 2. The tentative used width is greater than 'max-width', the rules above are applied again,
// but this time using the computed value of 'max-width' as the computed value for 'width'.
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (!should_treat_max_width_as_none(box, available_space.width)) {
LibWeb: Treat % max-width as none when containing block size indefinite This is technically "undefined behavior" per CSS 2.2, but it seems sensible to mirror the behavior of max-height in the same situation. It also appears to match how other engines behave. Fixes #19242
2023-06-14 18:35:02 +02:00
auto const& computed_max_width = box.computed_values().max_width();
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
if (used_width > computed_max_width.to_px(box, width_of_containing_block)) {
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
used_width = tentative_width_for_replaced_element(box, computed_max_width, available_space);
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
}
}
// 3. If the resulting width is smaller than 'min-width', the rules above are applied again,
// but this time using the value of 'min-width' as the computed value for 'width'.
LibWeb: Bring sizing of replaced elements closer to spec We were prematurely resolving the computed size values, which meant that `auto` values were swallowed before we could resolve them via the intrinsic aspect ratio (if present)
2022-07-11 12:28:35 +02:00
auto computed_min_width = box.computed_values().min_width();
if (!computed_min_width.is_auto()) {
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
if (used_width < computed_min_width.to_px(box, width_of_containing_block)) {
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
used_width = tentative_width_for_replaced_element(box, computed_min_width, available_space);
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
}
}
return used_width;
}
LibWeb: Cleanup + spec comments in replaced element height computation
2021-10-14 23:15:36 +02:00
// 10.6.2 Inline replaced elements, block-level replaced elements in normal flow, 'inline-block' replaced elements in normal flow and floating replaced elements
// https://www.w3.org/TR/CSS22/visudet.html#inline-replaced-height
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 FormattingContext::tentative_height_for_replaced_element(Box const& box, CSS::Size const& computed_height, AvailableSpace const& available_space) 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: 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
// If 'height' and 'width' both have computed values of 'auto' and the element also has
// an intrinsic height, then that intrinsic height is the used value of 'height'.
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (should_treat_width_as_auto(box, available_space) && should_treat_height_as_auto(box, available_space) && box.has_natural_height())
return box.natural_height().value();
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: Cleanup + spec comments in replaced element height computation
2021-10-14 23:15:36 +02:00
// Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic ratio then the used value of 'height' is:
//
// (used width) / (intrinsic ratio)
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
if (computed_height.is_auto() && box.has_preferred_aspect_ratio())
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
return m_state.get(box).content_width() / box.preferred_aspect_ratio().value();
LibWeb: Cleanup + spec comments in replaced element height computation
2021-10-14 23:15:36 +02:00
// Otherwise, if 'height' has a computed value of 'auto', and the element has an intrinsic height, then that intrinsic height is the used value of 'height'.
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (computed_height.is_auto() && box.has_natural_height())
return box.natural_height().value();
LibWeb: Cleanup + spec comments in replaced element height computation
2021-10-14 23:15:36 +02:00
// Otherwise, if 'height' has a computed value of 'auto', but none of the conditions above are met,
// then the used value of 'height' must be set to the height of the largest rectangle that has a 2:1 ratio, has a height not greater than 150px,
// and has a width not greater than the device width.
if (computed_height.is_auto())
return 150;
LibWeb: Use .to_px_or_zero() in tentative_height_for_replaced_element() If just .to_px() is used the height can end up as the float `inf` or `nan`. This caused an OOM when loading Polygon as this `inf` would become a `nan` and propagate to the SVG painting, which then attempts to draw a path with nan control points, which would make the Gfx::Painter infinitely split the path till it OOM'd.
2023-05-11 22:14:31 +01:00
// FIXME: Handle cases when available_space is not definite.
LibWeb: Return CSSPixels from `calculate_inner_height()` Similar to calculate_inner_width(), let's make the caller responsible for handling "auto" instead of returning the input height as is when when it cannot be resolved.
2024-01-07 05:46:36 +01:00
return calculate_inner_height(box, available_space.height, computed_height);
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: 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 FormattingContext::compute_height_for_replaced_element(Box const& box, AvailableSpace const& available_space) 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: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
// 10.6.2 Inline replaced elements
// 10.6.4 Block-level replaced elements in normal flow
// 10.6.6 Floating replaced elements
// 10.6.10 'inline-block' replaced elements in normal flow
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: Fix spelling of non_anonymous_containing_block()
2023-06-14 15:31:40 +02:00
auto height_of_containing_block = m_state.get(*box.non_anonymous_containing_block()).content_height();
LibWeb: Treat unresolvable percentage sizes as auto on replaced elements For replaced elements with percentage width or height, we were treating them as 0 instead of auto when their containing block had an indefinite corresponding size. This produced incorrect layouts in various cases, and although I can't actually find something about this exact scenario in specs, the new behavior does match other browsers.
2022-11-03 18:46:50 +01:00
auto computed_width = should_treat_width_as_auto(box, available_space) ? CSS::Size::make_auto() : box.computed_values().width();
auto computed_height = should_treat_height_as_auto(box, available_space) ? CSS::Size::make_auto() : box.computed_values().height();
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: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
// 1. The tentative used height is calculated (without 'min-height' and 'max-height')
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
CSSPixels used_height = tentative_height_for_replaced_element(box, computed_height, available_space);
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: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
// However, for replaced elements with both 'width' and 'height' computed as 'auto',
// use the algorithm under 'Minimum and maximum widths'
// https://www.w3.org/TR/CSS22/visudet.html#min-max-widths
// to find the used width and height.
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
if (computed_width.is_auto() && computed_height.is_auto() && box.has_preferred_aspect_ratio()) {
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
CSSPixels w = tentative_width_for_replaced_element(box, computed_width, available_space);
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 h = used_height;
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
used_height = solve_replaced_size_constraint(w, h, box, available_space).height();
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
return used_height;
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: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
// 2. If this tentative height is greater than 'max-height', the rules above are applied again,
// but this time using the value of 'max-height' as the computed value for 'height'.
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (!should_treat_max_height_as_none(box, available_space.height)) {
LibWeb: Treat % max-height as none when containing block size indefinite Fixes #19371
2023-06-14 15:33:06 +02:00
auto const& computed_max_height = box.computed_values().max_height();
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
if (used_height > computed_max_height.to_px(box, height_of_containing_block)) {
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
used_height = tentative_height_for_replaced_element(box, computed_max_height, available_space);
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
}
}
LibWeb: Enforce min/max height constraints on abspos replaced boxes Fixes #18658
2023-05-06 20:51:56 +02:00
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
// 3. If the resulting height is smaller than 'min-height', the rules above are applied again,
// but this time using the value of 'min-height' as the computed value for 'height'.
auto computed_min_height = box.computed_values().min_height();
if (!computed_min_height.is_auto()) {
if (used_height < computed_min_height.to_px(box, height_of_containing_block)) {
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
used_height = tentative_height_for_replaced_element(box, computed_min_height, available_space);
LibWeb: Improve handling of min/max constraint violations on images Instead of bailing after resolving one violated constraint, we have to continue down the list of remaining constraints. We now also call the constraint solver for all replaced elements with "auto" for both width and height. Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
2023-05-09 09:56:30 +02:00
}
}
LibWeb: Enforce min/max height constraints on abspos replaced boxes Fixes #18658
2023-05-06 20:51:56 +02:00
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
return used_height;
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
void FormattingContext::compute_width_for_absolutely_positioned_non_replaced_element(Box const& box, AvailableSpace const& available_space)
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: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
auto width_of_containing_block = available_space.width.to_px_or_zero();
LibWeb: Compute content width before static position for abspos elements In some scenarios, correctly computing the static position may depend on the content width having been calculated beforehand.
2024-03-02 21:53:25 +04:00
auto const& computed_values = box.computed_values();
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
auto zero_value = CSS::Length::make_px(0);
auto margin_left = CSS::Length::make_auto();
auto margin_right = CSS::Length::make_auto();
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
auto const border_left = computed_values.border_left().width;
auto const border_right = computed_values.border_right().width;
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
auto const padding_left = computed_values.padding().left().to_px(box, width_of_containing_block);
auto const padding_right = computed_values.padding().right().to_px(box, width_of_containing_block);
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: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
auto computed_left = computed_values.inset().left();
auto computed_right = computed_values.inset().right();
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
auto left = computed_values.inset().left().to_px(box, width_of_containing_block);
auto right = computed_values.inset().right().to_px(box, width_of_containing_block);
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
auto try_compute_width = [&](CSS::Length const& a_width) {
LibWeb: Add `Length::resolved()` overload for CSSPixels Since we always pass the px value as an argument to resolved(), we can pass it directly as CSSPixels instead of wrapping it in Length. This approach allows us to avoid converting to a double, resulting in fewer precision issues.
2023-08-29 18:57:09 +02:00
margin_left = computed_values.margin().left().resolved(box, width_of_containing_block);
margin_right = computed_values.margin().right().resolved(box, width_of_containing_block);
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
auto width = a_width;
auto solve_for_left = [&] {
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
return width_of_containing_block - margin_left.to_px(box) - border_left - padding_left - width.to_px(box) - padding_right - border_right - margin_right.to_px(box) - right;
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
};
auto solve_for_width = [&] {
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
return CSS::Length::make_px(max(CSSPixels(0), width_of_containing_block - left - margin_left.to_px(box) - border_left - padding_left - padding_right - border_right - margin_right.to_px(box) - right));
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
};
auto solve_for_right = [&] {
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
return width_of_containing_block - left - margin_left.to_px(box) - border_left - padding_left - width.to_px(box) - padding_right - border_right - margin_right.to_px(box);
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
};
// If all three of 'left', 'width', and 'right' are 'auto':
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
if (computed_left.is_auto() && width.is_auto() && computed_right.is_auto()) {
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
// First set any 'auto' values for 'margin-left' and 'margin-right' to 0.
if (margin_left.is_auto())
margin_left = CSS::Length::make_px(0);
if (margin_right.is_auto())
margin_right = CSS::Length::make_px(0);
// Then, if the 'direction' property of the element establishing the static-position containing block
// is 'ltr' set 'left' to the static position and apply rule number three below;
// otherwise, set 'right' to the static position and apply rule number one below.
LibWeb: Compute content width before static position for abspos elements In some scenarios, correctly computing the static position may depend on the content width having been calculated beforehand.
2024-03-02 21:53:25 +04:00
// NOTE: As with compute_height_for_absolutely_positioned_non_replaced_element, we actually apply these
// steps in the opposite order since the static position may depend on the width of the box.
auto result = calculate_shrink_to_fit_widths(box);
auto available_width = solve_for_width();
CSSPixels content_width = min(max(result.preferred_minimum_width, available_width.to_px(box)), result.preferred_width);
width = CSS::Length::make_px(content_width);
m_state.get_mutable(box).set_content_width(content_width);
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
auto static_position = calculate_static_position(box);
LibWeb: Compute content width before static position for abspos elements In some scenarios, correctly computing the static position may depend on the content width having been calculated beforehand.
2024-03-02 21:53:25 +04:00
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
left = static_position.x();
LibWeb: Compute content width before static position for abspos elements In some scenarios, correctly computing the static position may depend on the content width having been calculated beforehand.
2024-03-02 21:53:25 +04:00
right = solve_for_right();
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: Resolve auto margins on abspos elements in more cases Specifically, we now handle cases where all three of `left`, `width` and `right` are non-`auto`.
2023-06-13 16:25:11 +02:00
// If none of the three is auto:
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
if (!computed_left.is_auto() && !width.is_auto() && !computed_right.is_auto()) {
LibWeb: Resolve auto margins on abspos elements in more cases Specifically, we now handle cases where all three of `left`, `width` and `right` are non-`auto`.
2023-06-13 16:25:11 +02:00
// If both margin-left and margin-right are auto,
// solve the equation under the extra constraint that the two margins get equal values
// FIXME: unless this would make them negative, in which case when direction of the containing block is ltr (rtl), set margin-left (margin-right) to 0 and solve for margin-right (margin-left).
LibWeb: Subtract left inset from size_available_for_margins for abspos Fixes https://github.com/LadybirdBrowser/ladybird/issues/712
2024-07-19 13:58:59 +02:00
auto size_available_for_margins = width_of_containing_block - border_left - padding_left - width.to_px(box) - padding_right - border_right - left - right;
LibWeb: Resolve auto margins on abspos elements in more cases Specifically, we now handle cases where all three of `left`, `width` and `right` are non-`auto`.
2023-06-13 16:25:11 +02:00
if (margin_left.is_auto() && margin_right.is_auto()) {
margin_left = CSS::Length::make_px(size_available_for_margins / 2);
margin_right = CSS::Length::make_px(size_available_for_margins / 2);
return width;
}
// If one of margin-left or margin-right is auto, solve the equation for that value.
if (margin_left.is_auto()) {
margin_left = CSS::Length::make_px(size_available_for_margins);
return width;
}
if (margin_right.is_auto()) {
margin_right = CSS::Length::make_px(size_available_for_margins);
return width;
}
// If the values are over-constrained, ignore the value for left
// (in case the direction property of the containing block is rtl)
// or right (in case direction is ltr) and solve for that value.
// NOTE: At this point we *are* over-constrained since none of margin-left, left, width, right, or margin-right are auto.
// FIXME: Check direction.
right = solve_for_right();
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
return width;
}
if (margin_left.is_auto())
margin_left = CSS::Length::make_px(0);
if (margin_right.is_auto())
margin_right = CSS::Length::make_px(0);
// 1. 'left' and 'width' are 'auto' and 'right' is not 'auto',
// then the width is shrink-to-fit. Then solve for 'left'
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
if (computed_left.is_auto() && width.is_auto() && !computed_right.is_auto()) {
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
auto result = calculate_shrink_to_fit_widths(box);
auto available_width = solve_for_width();
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
width = CSS::Length::make_px(min(max(result.preferred_minimum_width, available_width.to_px(box)), result.preferred_width));
LibWeb: Solve width for absolute positioned elemenent according to spec https://www.w3.org/TR/css-position-3/#abs-non-replaced-width If left and width are auto and right is not auto, then the width is shrink-to-fit. Then solve for left.
2022-11-16 03:57:38 +03:00
left = solve_for_left();
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
}
// 2. 'left' and 'right' are 'auto' and 'width' is not 'auto',
// then if the 'direction' property of the element establishing
// the static-position containing block is 'ltr' set 'left'
// to the static position, otherwise set 'right' to the static position.
// Then solve for 'left' (if 'direction is 'rtl') or 'right' (if 'direction' is 'ltr').
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
else if (computed_left.is_auto() && computed_right.is_auto() && !width.is_auto()) {
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
// FIXME: Check direction
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
auto static_position = calculate_static_position(box);
left = static_position.x();
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
right = solve_for_right();
}
// 3. 'width' and 'right' are 'auto' and 'left' is not 'auto',
// then the width is shrink-to-fit. Then solve for 'right'
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
else if (width.is_auto() && computed_right.is_auto() && !computed_left.is_auto()) {
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
auto result = calculate_shrink_to_fit_widths(box);
auto available_width = solve_for_width();
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
width = CSS::Length::make_px(min(max(result.preferred_minimum_width, available_width.to_px(box)), result.preferred_width));
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
right = solve_for_right();
}
// 4. 'left' is 'auto', 'width' and 'right' are not 'auto', then solve for 'left'
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
else if (computed_left.is_auto() && !width.is_auto() && !computed_right.is_auto()) {
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
left = solve_for_left();
}
// 5. 'width' is 'auto', 'left' and 'right' are not 'auto', then solve for 'width'
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
else if (width.is_auto() && !computed_left.is_auto() && !computed_right.is_auto()) {
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
width = solve_for_width();
}
// 6. 'right' is 'auto', 'left' and 'width' are not 'auto', then solve for 'right'
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
else if (computed_right.is_auto() && !computed_left.is_auto() && !width.is_auto()) {
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
right = solve_for_right();
}
return width;
};
// 1. The tentative used width is calculated (without 'min-width' and 'max-width')
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
auto used_width = try_compute_width([&] {
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
if (is<TableWrapper>(box))
return CSS::Length::make_px(compute_table_box_width_inside_table_wrapper(box, available_space));
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
if (computed_values.width().is_auto())
return CSS::Length::make_auto();
return CSS::Length::make_px(calculate_inner_width(box, available_space.width, computed_values.width()));
}());
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
// 2. The tentative used width is greater than 'max-width', the rules above are applied again,
// but this time using the computed value of 'max-width' as the computed value for 'width'.
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (!should_treat_max_width_as_none(box, available_space.width)) {
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
auto max_width = calculate_inner_width(box, available_space.width, computed_values.max_width());
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
if (used_width.to_px(box) > max_width) {
used_width = try_compute_width(CSS::Length::make_px(max_width));
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
}
}
// 3. If the resulting width is smaller than 'min-width', the rules above are applied again,
// but this time using the value of 'min-width' as the computed value for 'width'.
LibWeb: Use CSS::Size for computed size and max-size values This patch changes the *computed* representation of the following CSS properties to use CSS::Size: - width, min-width, max-width - height, min-height, max-height A few things had to change in order for things to keep working, but I tried to keep the diff to a minimum. The main trouble was that `min-width` and `max-width` can't actually be `auto`, but they *can* be `none`. We previously treated `auto` as a valid value (and it behaved mostly like `none`).
2022-09-25 15:48:23 +02:00
if (!computed_values.min_width().is_auto()) {
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
auto min_width = calculate_inner_width(box, available_space.width, computed_values.min_width());
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
if (used_width.to_px(box) < min_width) {
used_width = try_compute_width(CSS::Length::make_px(min_width));
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: 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
auto& box_state = m_state.get_mutable(box);
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
box_state.set_content_width(used_width.to_px(box));
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
box_state.inset_left = left;
box_state.inset_right = right;
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_state.margin_left = margin_left.to_px(box);
box_state.margin_right = margin_right.to_px(box);
box_state.padding_left = padding_left;
box_state.padding_right = padding_right;
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: 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 FormattingContext::compute_width_for_absolutely_positioned_replaced_element(Box const& box, AvailableSpace const& available_space)
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: Compute width of absolutely positioned, replaced elements Fixes #4589.
2021-01-06 19:16:40 +01:00
// 10.3.8 Absolutely positioned, replaced elements
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
// In this case, section 10.3.7 applies up through and including the constraint equation,
// but the rest of section 10.3.7 is replaced by the following rules:
// 1. The used value of 'width' is determined as for inline replaced elements.
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
if (is<ReplacedBox>(box)) {
// FIXME: This const_cast is gross.
static_cast<ReplacedBox&>(const_cast<Box&>(box)).prepare_for_replaced_layout();
}
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
auto width = compute_width_for_replaced_element(box, available_space);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
auto width_of_containing_block = available_space.width.to_px_or_zero();
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
auto available = width_of_containing_block - width;
auto const& computed_values = box.computed_values();
auto left = computed_values.inset().left();
auto margin_left = computed_values.margin().left();
auto right = computed_values.inset().right();
auto margin_right = computed_values.margin().right();
auto static_position = calculate_static_position(box);
auto to_px = [&](const CSS::LengthPercentage& l) {
return l.to_px(box, width_of_containing_block);
};
// If 'margin-left' or 'margin-right' is specified as 'auto' its used value is determined by the rules below.
// 2. If both 'left' and 'right' have the value 'auto', then if the 'direction' property of the
// element establishing the static-position containing block is 'ltr', set 'left' to the static
// position; else if 'direction' is 'rtl', set 'right' to the static position.
if (left.is_auto() && right.is_auto()) {
left = CSS::Length::make_px(static_position.x());
}
// 3. If 'left' or 'right' are 'auto', replace any 'auto' on 'margin-left' or 'margin-right' with '0'.
if (left.is_auto() || right.is_auto()) {
if (margin_left.is_auto())
margin_left = CSS::Length::make_px(0);
if (margin_right.is_auto())
margin_right = CSS::Length::make_px(0);
}
// 4. If at this point both 'margin-left' and 'margin-right' are still 'auto', solve the equation
// under the extra constraint that the two margins must get equal values, unless this would make
// them negative, in which case when the direction of the containing block is 'ltr' ('rtl'),
// set 'margin-left' ('margin-right') to zero and solve for 'margin-right' ('margin-left').
if (margin_left.is_auto() && margin_right.is_auto()) {
auto remainder = available - to_px(left) - to_px(right);
if (remainder < 0) {
margin_left = CSS::Length::make_px(0);
margin_right = CSS::Length::make_px(0);
} else {
margin_left = CSS::Length::make_px(remainder / 2);
margin_right = CSS::Length::make_px(remainder / 2);
}
}
// 5. If at this point there is an 'auto' left, solve the equation for that value.
if (left.is_auto()) {
left = CSS::Length::make_px(available - to_px(right) - to_px(margin_left) - to_px(margin_right));
} else if (right.is_auto()) {
right = CSS::Length::make_px(available - to_px(left) - to_px(margin_left) - to_px(margin_right));
} else if (margin_left.is_auto()) {
margin_left = CSS::Length::make_px(available - to_px(left) - to_px(right) - to_px(margin_right));
} else if (margin_right.is_auto()) {
margin_right = CSS::Length::make_px(available - to_px(left) - to_px(margin_left) - to_px(right));
}
// 6. If at this point the values are over-constrained, ignore the value for either 'left'
// (in case the 'direction' property of the containing block is 'rtl') or 'right'
// (in case 'direction' is 'ltr') and solve for that value.
if (0 != available - to_px(left) - to_px(right) - to_px(margin_left) - to_px(margin_right)) {
right = CSS::Length::make_px(available - to_px(left) - to_px(margin_left) - to_px(margin_right));
}
auto& box_state = m_state.get_mutable(box);
box_state.inset_left = to_px(left);
box_state.inset_right = to_px(right);
box_state.margin_left = to_px(margin_left);
box_state.margin_right = to_px(margin_right);
box_state.set_content_width(width);
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: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
// https://drafts.csswg.org/css-position-3/#abs-non-replaced-height
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
void FormattingContext::compute_height_for_absolutely_positioned_non_replaced_element(Box const& box, AvailableSpace const& available_space, BeforeOrAfterInsideLayout before_or_after_inside_layout)
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: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
// 5.3. The Height Of Absolutely Positioned, Non-Replaced Elements
LibWeb: Improve height:auto for position:absolute blocks Previously we were not giving automatic height to position:absolute blocks that had both top:auto and bottom:auto.
2022-03-05 16:02:53 +01:00
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
// For absolutely positioned elements, the used values of the vertical dimensions must satisfy this constraint:
// top + margin-top + border-top-width + padding-top + height + padding-bottom + border-bottom-width + margin-bottom + bottom = height of containing block
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
// NOTE: This function is called twice: both before and after inside layout.
// In the before pass, if it turns out we need the automatic height of the box, we abort these steps.
// This allows the box to retain an indefinite height from the perspective of inside layout.
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto apply_min_max_height_constraints = [this, &box, &available_space](CSS::Length unconstrained_height) -> CSS::Length {
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
auto const& computed_min_height = box.computed_values().min_height();
auto const& computed_max_height = box.computed_values().max_height();
auto constrained_height = unconstrained_height;
if (!computed_max_height.is_none()) {
auto inner_max_height = calculate_inner_height(box, available_space.height, computed_max_height);
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
if (inner_max_height < constrained_height.to_px(box))
constrained_height = CSS::Length::make_px(inner_max_height);
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
}
if (!computed_min_height.is_auto()) {
auto inner_min_height = calculate_inner_height(box, available_space.height, computed_min_height);
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
if (inner_min_height > constrained_height.to_px(box))
constrained_height = CSS::Length::make_px(inner_min_height);
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
}
return constrained_height;
};
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
auto margin_top = box.computed_values().margin().top();
auto margin_bottom = box.computed_values().margin().bottom();
auto top = box.computed_values().inset().top();
auto bottom = box.computed_values().inset().bottom();
LibWeb: Make automatic heights for abspos non-replaced behave better Previously we were checking if values were "auto" after resolving the "auto"-ness out of them, which didn't work. There's still a bunch of work to do on this algorithm, but now we can at least resolve some basic automatic height scenarios.
2022-07-26 01:30:50 +02:00
LibWeb: Resolve *all* percentages in abspos height calculation We were neglecting to resolve() percentages for many values.
2022-10-12 11:14:45 +02:00
auto width_of_containing_block = containing_block_width_for(box);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
auto height_of_containing_block = available_space.height.to_px_or_zero();
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: Don't allow resolved height of abspos elements to become negative We have to clamp the resulting height to 0 when solving for it.
2023-03-25 17:20:52 +01:00
enum class ClampToZero {
No,
Yes,
};
LibWeb: Remove code duplication in computing height for abs-pos elements This refactors the solve_for_{top, bottom, height, etc} lambdas to use a common solve_for lambda that takes the length to be solved as an argument. This way some code duplication is removed.
2022-10-12 10:55:52 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto try_compute_height = [&](CSS::Length height) -> CSS::Length {
auto solve_for = [&](CSS::Length length, ClampToZero clamp_to_zero = ClampToZero::No) {
auto unclamped_value = height_of_containing_block
- top.to_px(box, height_of_containing_block)
- margin_top.to_px(box, width_of_containing_block)
- box.computed_values().border_top().width
- box.computed_values().padding().top().to_px(box, width_of_containing_block)
LibWeb: When solving abspos lengths, use min max constrained height Solving using the unconstrained height, when solving for bottom, would either leave a gap over overflow its container.
2024-07-10 17:39:06 +01:00
- apply_min_max_height_constraints(height).to_px(box)
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
- box.computed_values().padding().bottom().to_px(box, width_of_containing_block)
- box.computed_values().border_bottom().width
- margin_bottom.to_px(box, width_of_containing_block)
- bottom.to_px(box, height_of_containing_block)
+ length.to_px(box);
if (clamp_to_zero == ClampToZero::Yes)
return CSS::Length::make_px(max(CSSPixels(0), unclamped_value));
return CSS::Length::make_px(unclamped_value);
};
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: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_top = [&] {
top = solve_for(top.resolved(box, height_of_containing_block));
};
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: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_bottom = [&] {
bottom = solve_for(bottom.resolved(box, height_of_containing_block));
};
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_height = [&] {
height = solve_for(height, ClampToZero::Yes);
};
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_margin_top = [&] {
margin_top = solve_for(margin_top.resolved(box, width_of_containing_block));
};
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_margin_bottom = [&] {
margin_bottom = solve_for(margin_bottom.resolved(box, width_of_containing_block));
};
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto solve_for_margin_top_and_margin_bottom = [&] {
auto remainder = solve_for(CSS::Length::make_px(margin_top.to_px(box, width_of_containing_block) + margin_bottom.to_px(box, width_of_containing_block))).to_px(box);
margin_top = CSS::Length::make_px(remainder / 2);
margin_bottom = CSS::Length::make_px(remainder / 2);
};
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// If all three of top, height, and bottom are auto:
if (top.is_auto() && height.is_auto() && bottom.is_auto()) {
// First set any auto values for margin-top and margin-bottom to 0,
if (margin_top.is_auto())
margin_top = CSS::Length::make_px(0);
if (margin_bottom.is_auto())
margin_bottom = CSS::Length::make_px(0);
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// then set top to the static position,
// and finally apply rule number three below.
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// NOTE: We actually perform these two steps in the opposite order,
// because the static position may depend on the height of the box (due to alignment properties).
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto maybe_height = compute_auto_height_for_absolutely_positioned_element(box, available_space, before_or_after_inside_layout);
if (!maybe_height.has_value())
return height;
height = CSS::Length::make_px(maybe_height.value());
LibWeb: Improve height:auto for position:absolute blocks Previously we were not giving automatic height to position:absolute blocks that had both top:auto and bottom:auto.
2022-03-05 16:02:53 +01:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto constrained_height = apply_min_max_height_constraints(height);
m_state.get_mutable(box).set_content_height(constrained_height.to_px(box));
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto static_position = calculate_static_position(box);
top = CSS::Length::make_px(static_position.y());
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
solve_for_bottom();
}
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// If none of the three are auto:
else if (!top.is_auto() && !height.is_auto() && !bottom.is_auto()) {
// If both margin-top and margin-bottom are auto,
if (margin_top.is_auto() && margin_bottom.is_auto()) {
// solve the equation under the extra constraint that the two margins get equal values.
solve_for_margin_top_and_margin_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// If one of margin-top or margin-bottom is auto,
else if (margin_top.is_auto() || margin_bottom.is_auto()) {
// solve the equation for that value.
if (margin_top.is_auto())
solve_for_margin_top();
else
solve_for_margin_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// If the values are over-constrained,
else {
// ignore the value for bottom and solve for that value.
solve_for_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
}
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// Otherwise,
else {
// set auto values for margin-top and margin-bottom to 0,
if (margin_top.is_auto())
margin_top = CSS::Length::make_px(0);
if (margin_bottom.is_auto())
margin_bottom = CSS::Length::make_px(0);
// and pick one of the following six rules that apply.
// 1. If top and height are auto and bottom is not auto,
if (top.is_auto() && height.is_auto() && !bottom.is_auto()) {
// then the height is based on the Auto heights for block formatting context roots,
auto maybe_height = compute_auto_height_for_absolutely_positioned_element(box, available_space, before_or_after_inside_layout);
if (!maybe_height.has_value())
return height;
height = CSS::Length::make_px(maybe_height.value());
// and solve for top.
solve_for_top();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// 2. If top and bottom are auto and height is not auto,
else if (top.is_auto() && bottom.is_auto() && !height.is_auto()) {
// then set top to the static position,
top = CSS::Length::make_px(calculate_static_position(box).y());
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// then solve for bottom.
solve_for_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// 3. If height and bottom are auto and top is not auto,
else if (height.is_auto() && bottom.is_auto() && !top.is_auto()) {
// then the height is based on the Auto heights for block formatting context roots,
auto maybe_height = compute_auto_height_for_absolutely_positioned_element(box, available_space, before_or_after_inside_layout);
if (!maybe_height.has_value())
return height;
height = CSS::Length::make_px(maybe_height.value());
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// and solve for bottom.
solve_for_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// 4. If top is auto, height and bottom are not auto,
else if (top.is_auto() && !height.is_auto() && !bottom.is_auto()) {
// then solve for top.
solve_for_top();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
// 5. If height is auto, top and bottom are not auto,
else if (height.is_auto() && !top.is_auto() && !bottom.is_auto()) {
// then solve for height.
solve_for_height();
}
// 6. If bottom is auto, top and height are not auto,
else if (bottom.is_auto() && !top.is_auto() && !height.is_auto()) {
// then solve for bottom.
solve_for_bottom();
}
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
}
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
return height;
};
LibWeb: Compute height of absolutely positioned blocks when possible Section 10.6.4 rule 5 of the CSS height property spec outlines a method to compute the height of an absolutely positioned block when the 'top' and 'bottom' CSS properties are specified.
2021-03-26 17:01:44 -04:00
LibWeb: Fix for absolutely positioned elements with specified height Use inner height since the paintable adds padding back. Fixes #18842.
2023-05-15 06:33:06 +00:00
// Compute the height based on box type and CSS properties:
// https://www.w3.org/TR/css-sizing-3/#box-sizing
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
auto used_height = try_compute_height([&] {
if (is<TableWrapper>(box))
return CSS::Length::make_px(compute_table_box_height_inside_table_wrapper(box, available_space));
if (should_treat_height_as_auto(box, available_space))
return CSS::Length::make_auto();
return CSS::Length::make_px(calculate_inner_height(box, available_space.height, box.computed_values().height()));
}());
LibWeb: Constrain abspos element heights by min-height and max-height
2022-10-11 22:31:51 +02:00
LibWeb: Handle case where abspos flex child position depends on height There's a particularly awkward case where the static position of an abspos child of a flex container is dependent on its height. This can happen when `align-items: center` is in effect, as we have to adjust the abspos child's Y position by half of its height. This patch solves the issue by reordering operations in the abspos height resolution algorithm, to make sure that height is resolved before the static position is calculated.
2023-09-03 14:10:46 +02:00
used_height = apply_min_max_height_constraints(used_height);
LibWeb: Constrain abspos element heights by min-height and max-height
2022-10-11 22:31:51 +02:00
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
// NOTE: The following is not directly part of any spec, but this is where we resolve
// the final used values for vertical margin/border/padding.
LibWeb: Make automatic heights for abspos non-replaced behave better Previously we were checking if values were "auto" after resolving the "auto"-ness out of them, which didn't work. There's still a bunch of work to do on this algorithm, but now we can at least resolve some basic automatic height scenarios.
2022-07-26 01:30:50 +02:00
LibWeb: Calculate height of absolute-position elements according to spec This patch implements the full "old model" height algorithm from the CSS Positioned Layout spec. I went with the old model since we don't yet have the machinery required to implement the new model. Also, the width calculations already follow the old model, so this is symmetric with that. Eventually we should of course implement the new positioned layout model.
2022-10-11 19:04:09 +02:00
auto& box_state = m_state.get_mutable(box);
LibWeb: Account for absolutely positioned table wrappers Table wrappers don't quite behave the same as most elements, in that their computed height and width are not meant to be used for layout. Instead, we now calculate suitable widths and heights based on the contents of the table wrapper when performing absolute layout. Fixes the layout of http://wpt.live/css/css-position/position-absolute-center-007.html
2024-03-04 22:11:04 +04:00
box_state.set_content_height(used_height.to_px(box));
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
// do not set calculated insets or margins on the first pass, there will be a second pass
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return;
LibWeb: Resolve % top and bottom insets against containing block height This makes cookie banner buttons show up on Linktree again. :^) Regressed in fd37ad3a84e9330e89ce9aee22500e4c82144a8f
2023-07-08 09:49:37 +02:00
box_state.inset_top = top.to_px(box, height_of_containing_block);
box_state.inset_bottom = bottom.to_px(box, height_of_containing_block);
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
box_state.margin_top = margin_top.to_px(box, width_of_containing_block);
box_state.margin_bottom = margin_bottom.to_px(box, width_of_containing_block);
box_state.padding_top = box.computed_values().padding().top().to_px(box, width_of_containing_block);
box_state.padding_bottom = box.computed_values().padding().bottom().to_px(box, width_of_containing_block);
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: 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
// NOTE: This is different from content_box_rect_in_ancestor_coordinate_space() as this does *not* follow the containing block chain up, but rather the parent() chain.
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
CSSPixelRect FormattingContext::content_box_rect_in_static_position_ancestor_coordinate_space(Box const& box, Box const& ancestor_box) const
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: 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
auto rect = content_box_rect(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
if (&box == &ancestor_box)
return rect;
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
for (auto const* current = box.static_position_containing_block(); current; current = current->static_position_containing_block()) {
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
if (current == &ancestor_box)
return rect;
LibWeb: Remove some unnecessary static_casts to Layout::Box& UBSAN flagged one of these as invalid, and since it's not even necessary to cast here anymore, let's just not.
2023-09-04 12:31:23 +02:00
auto const& current_state = m_state.get(*current);
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
rect.translate_by(current_state.offset);
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
}
// If we get here, ancestor_box was not an ancestor of `box`!
VERIFY_NOT_REACHED();
}
// https://www.w3.org/TR/css-position-3/#staticpos-rect
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
CSSPixelPoint FormattingContext::calculate_static_position(Box const& box) const
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
{
// NOTE: This is very ad-hoc.
// The purpose of this function is to calculate the approximate position that `box`
// would have had if it were position:static.
LibWeb: Remove implicit conversion from float and double to CSSPixels In general it is not safe to convert any arbitrary floating-point value to CSSPixels. CSSPixels has a resolution of 0.015625, which for small values (e.g. scale factors between 0 and 1), can produce bad results if converted to CSSPixels then scaled back up. In the worst case values can underflow to zero and produce incorrect results.
2023-08-26 15:03:04 +01:00
CSSPixels x = 0;
CSSPixels y = 0;
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
VERIFY(box.parent());
if (box.parent()->children_are_inline()) {
// We're an abspos box with inline siblings. This is gonna get messy!
if (auto* sibling = box.previous_sibling()) {
// Hard case: there's a previous sibling. This means there's already inline content
// preceding the hypothetical static position of `box` within its containing block.
// If we had been position:static, that inline content would have been wrapped in
// anonymous block box, so now we get to imagine what the world might have looked like
// in that scenario..
// Basically, we find its last associated line box fragment and place `box` under it.
// FIXME: I'm 100% sure this can be smarter, better and faster.
LineBoxFragment const* last_fragment = nullptr;
auto& cb_state = m_state.get(*sibling->containing_block());
for (auto& line_box : cb_state.line_boxes) {
for (auto& fragment : line_box.fragments()) {
if (&fragment.layout_node() == sibling)
last_fragment = &fragment;
}
}
if (last_fragment) {
LibWeb+WebContent: Forbid access to underlying type of CSSPixels Although DistinctNumeric, which is supposed to abstract the underlying type, was used to represent CSSPixels, we have a whole bunch of places in the layout code that assume CSSPixels::value() returns a floating-point type. This assumption makes it difficult to replace the underlying type in CSSPixels with a non-floating type. To make it easier to transition CSSPixels to fixed-point math, one step we can take is to prevent access to the underlying type using value() and instead use explicit conversions with the to_float(), to_double(), and to_int() methods.
2023-06-12 21:37:35 +03:00
y = last_fragment->offset().y() + last_fragment->height();
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
}
} else {
// Easy case: no previous sibling, we're at the top of the containing block.
}
} else {
LibWeb: Use the parent container's y offset when finding static position Fixes #18819.
2024-03-08 14:09:42 +04:00
auto const& box_state = m_state.get(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
// We're among block siblings, Y can be calculated easily.
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
y = box_state.vertical_offset_of_parent_block_container;
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: 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
auto offset_to_static_parent = content_box_rect_in_static_position_ancestor_coordinate_space(box, *box.containing_block());
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
return offset_to_static_parent.location().translated(x, y);
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
void FormattingContext::layout_absolutely_positioned_element(Box const& box, AvailableSpace const& available_space)
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: Containing block always has definite width during abspos layout From CSS-SIZING-3: "...the size of the containing block of an absolutely positioned element is always definite with respect to that element."
2022-07-17 19:38:06 +02:00
auto& containing_block_state = m_state.get_mutable(*box.containing_block());
LibWeb: Mark fixed-length abspos element sizes as definite In particular, these two interesting cases: - The containing block of an abspos box is always definite from the perspective of the abspos box. - When resolving abspos box sizes from two opposing fixed insets, we now mark those sizes as definite (since no layout was required to resolve them).
2024-02-21 15:22:31 +01:00
// The size of the containing block of an abspos box is always definite from the perspective of the abspos box.
// Since abspos boxes are laid out last, we can mark the containing block as having definite sizes at this point.
containing_block_state.set_has_definite_width(true);
containing_block_state.set_has_definite_height(true);
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
auto& box_state = m_state.get_mutable(box);
LibWeb: Containing block always has definite width during abspos layout From CSS-SIZING-3: "...the size of the containing block of an absolutely positioned element is always definite with respect to that element."
2022-07-17 19:38:06 +02:00
LibWeb: Fix absolute positioning issues Make sure the insets and margins calculated according to the spec are not later ignored and ad-hoc recomputed in layout_absolutely_positioned_element. Use the static position calculation in a couple of places where the spec (and comment) was indicating it should be used. Fixes #19362
2023-07-07 15:24:57 +02:00
// The border computed values are not changed by the compute_height & width calculations below.
// The spec only adjusts and computes sizes, insets and margins.
box_state.border_left = box.computed_values().border_left().width;
box_state.border_right = box.computed_values().border_right().width;
box_state.border_top = box.computed_values().border_top().width;
box_state.border_bottom = box.computed_values().border_bottom().width;
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
compute_width_for_absolutely_positioned_element(box, available_space);
LibWeb: Try to compute height for abspos elements before inside layout This can resolve height early in some cases, notably this kind of setup: position: absolute; top: 0px; bottom: 0px; By resolving height before inside layout, descendants of the abspos element can resolve automatic and relative vertical lengths against it. This makes the Discord UI occupy the whole window instead of looking "shrink-to-fit".
2022-11-09 15:11:21 +01:00
// NOTE: We compute height before *and* after doing inside layout.
// This is done so that inside layout can resolve percentage heights.
LibWeb: Finish half-written comment in abspos height calculation Apparently I forgot to write the whole comment in the previous commit, 8a87f4fa207da2ec40665e6125bffd2a6f7425e2.
2022-11-09 16:16:10 +01:00
// In some situations, e.g with non-auto top & bottom values, the height can be determined early.
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
compute_height_for_absolutely_positioned_element(box, available_space, BeforeOrAfterInsideLayout::Before);
LibWeb: Try to compute height for abspos elements before inside layout This can resolve height early in some cases, notably this kind of setup: position: absolute; top: 0px; bottom: 0px; By resolving height before inside layout, descendants of the abspos element can resolve automatic and relative vertical lengths against it. This makes the Discord UI occupy the whole window instead of looking "shrink-to-fit".
2022-11-09 15:11:21 +01:00
LibWeb: Mark fixed-length abspos element sizes as definite In particular, these two interesting cases: - The containing block of an abspos box is always definite from the perspective of the abspos box. - When resolving abspos box sizes from two opposing fixed insets, we now mark those sizes as definite (since no layout was required to resolve them).
2024-02-21 15:22:31 +01:00
// If the box width and/or height is fixed and/or or resolved from inset properties,
// mark the size as being definite (since layout was not required to resolve it, per CSS-SIZING-3).
if (box.computed_values().inset().left().is_length() && box.computed_values().inset().right().is_length()) {
box_state.set_has_definite_width(true);
}
if (box.computed_values().inset().top().is_length() && box.computed_values().inset().bottom().is_length()) {
box_state.set_has_definite_height(true);
}
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
auto independent_formatting_context = layout_inside(box, LayoutMode::Normal, box_state.available_inner_space_or_constraints_from(available_space));
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
compute_height_for_absolutely_positioned_element(box, available_space, BeforeOrAfterInsideLayout::After);
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: 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
CSSPixelPoint used_offset;
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
auto static_position = calculate_static_position(box);
if (box.computed_values().inset().top().is_auto() && box.computed_values().inset().bottom().is_auto()) {
used_offset.set_y(static_position.y());
} else {
used_offset.set_y(box_state.inset_top);
// NOTE: Absolutely positioned boxes are relative to the *padding edge* of the containing block.
LibWeb: Do not compensate padding for abspos boxes with static position When a box does not have a top, left, bottom, or right, there is no need to adjust the offset for positioning relative to the padding edge, because the box remains in the normal flow.
2023-11-15 13:32:16 +01:00
used_offset.translate_by(0, -containing_block_state.padding_top);
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
}
if (box.computed_values().inset().left().is_auto() && box.computed_values().inset().right().is_auto()) {
used_offset.set_x(static_position.x());
} else {
used_offset.set_x(box_state.inset_left);
// NOTE: Absolutely positioned boxes are relative to the *padding edge* of the containing block.
LibWeb: Do not compensate padding for abspos boxes with static position When a box does not have a top, left, bottom, or right, there is no need to adjust the offset for positioning relative to the padding edge, because the box remains in the normal flow.
2023-11-15 13:32:16 +01:00
used_offset.translate_by(-containing_block_state.padding_left, 0);
LibWeb: Use static position for abspos box axes with auto insets When both insets in a given axis are auto, we should use the static position for absolutely positioned elements. By doing this correctly, we exposed a bunch of other small bugs which had to be fixed to compensate for new test failures. Those fixes are included here as well: - Don't apply margins twice. - Compute the static position containing block chain correctly. This makes https://brave.com/ look much better. :^)
2024-04-11 21:54:37 +02:00
}
used_offset.translate_by(box_state.margin_box_left(), box_state.margin_box_top());
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
box_state.set_content_offset(used_offset);
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
if (independent_formatting_context)
independent_formatting_context->parent_context_did_dimension_child_root_box();
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: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
void FormattingContext::compute_height_for_absolutely_positioned_replaced_element(Box const& box, AvailableSpace const& available_space, BeforeOrAfterInsideLayout before_or_after_inside_layout)
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: Compute intrinsic height of absolute replaced elements Previously, the method for computing the height of absolutely positioned replaced elements only invoked the method for non-replaced elements. That method is now implemented fully enough that it sometimes computed a height of 0 for replaced elements. This implements section 10.6.5 rule 1 of the CSS spec to avoid that behavior.
2021-05-04 10:14:58 -04:00
// 10.6.5 Absolutely positioned, replaced elements
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
// This situation is similar to 10.6.4, except that the element has an intrinsic height.
LibWeb: Compute intrinsic height of absolute replaced elements Previously, the method for computing the height of absolutely positioned replaced elements only invoked the method for non-replaced elements. That method is now implemented fully enough that it sometimes computed a height of 0 for replaced elements. This implements section 10.6.5 rule 1 of the CSS spec to avoid that behavior.
2021-05-04 10:14:58 -04:00
// The used value of 'height' is determined as for inline replaced elements.
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
auto height = compute_height_for_replaced_element(box, available_space);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
auto height_of_containing_block = available_space.height.to_px_or_zero();
LibWeb: Implement abspos for replaced elements Added implementation and spec comments for sections 10.3.8 and 10.6.5, with an implementation similar to the existing ones for non-replaced elements.
2023-07-04 22:46:58 +02:00
auto available = height_of_containing_block - height;
auto const& computed_values = box.computed_values();
auto top = computed_values.inset().top();
auto margin_top = computed_values.margin().top();
auto bottom = computed_values.inset().bottom();
auto margin_bottom = computed_values.margin().bottom();
auto static_position = calculate_static_position(box);
auto to_px = [&](const CSS::LengthPercentage& l) {
return l.to_px(box, height_of_containing_block);
};
// If 'margin-top' or 'margin-bottom' is specified as 'auto' its used value is determined by the rules below.
// 2. If both 'top' and 'bottom' have the value 'auto', replace 'top' with the element's static position.
if (top.is_auto() && bottom.is_auto()) {
top = CSS::Length::make_px(static_position.x());
}
// 3. If 'bottom' is 'auto', replace any 'auto' on 'margin-top' or 'margin-bottom' with '0'.
if (bottom.is_auto()) {
if (margin_top.is_auto())
margin_top = CSS::Length::make_px(0);
if (margin_bottom.is_auto())
margin_bottom = CSS::Length::make_px(0);
}
// 4. If at this point both 'margin-top' and 'margin-bottom' are still 'auto',
// solve the equation under the extra constraint that the two margins must get equal values.
if (margin_top.is_auto() && margin_bottom.is_auto()) {
auto remainder = available - to_px(top) - to_px(bottom);
margin_top = CSS::Length::make_px(remainder / 2);
margin_bottom = CSS::Length::make_px(remainder / 2);
}
// 5. If at this point there is an 'auto' left, solve the equation for that value.
if (top.is_auto()) {
top = CSS::Length::make_px(available - to_px(bottom) - to_px(margin_top) - to_px(margin_bottom));
} else if (bottom.is_auto()) {
bottom = CSS::Length::make_px(available - to_px(top) - to_px(margin_top) - to_px(margin_bottom));
} else if (margin_top.is_auto()) {
margin_top = CSS::Length::make_px(available - to_px(top) - to_px(bottom) - to_px(margin_bottom));
} else if (margin_bottom.is_auto()) {
margin_bottom = CSS::Length::make_px(available - to_px(top) - to_px(margin_top) - to_px(bottom));
}
// 6. If at this point the values are over-constrained, ignore the value for 'bottom' and solve for that value.
if (0 != available - to_px(top) - to_px(bottom) - to_px(margin_top) - to_px(margin_bottom)) {
bottom = CSS::Length::make_px(available - to_px(top) - to_px(margin_top) - to_px(margin_bottom));
}
auto& box_state = m_state.get_mutable(box);
box_state.set_content_height(height);
// do not set calculated insets or margins on the first pass, there will be a second pass
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return;
box_state.inset_top = to_px(top);
box_state.inset_bottom = to_px(bottom);
box_state.margin_top = to_px(margin_top);
box_state.margin_bottom = to_px(margin_bottom);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
}
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
// https://www.w3.org/TR/css-position-3/#relpos-insets
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
void FormattingContext::compute_inset(NodeWithStyleAndBoxModelMetrics const& box)
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
{
LibWeb: Rename "position" enum to "positioning" The postitioning enum values are used by the position CSS property. Unfortunately, the prior naming clashes with the CSS Values-4 type named position, which will be implemented in a later commit.
2023-10-27 15:17:36 +02:00
if (box.computed_values().position() != CSS::Positioning::Relative)
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
return;
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
auto resolve_two_opposing_insets = [&](CSS::LengthPercentage const& computed_first, CSS::LengthPercentage const& computed_second, CSSPixels& used_start, CSSPixels& used_end, CSSPixels reference_for_percentage) {
auto resolved_first = computed_first.to_px(box, reference_for_percentage);
auto resolved_second = computed_second.to_px(box, reference_for_percentage);
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
if (computed_first.is_auto() && computed_second.is_auto()) {
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
// If opposing inset properties in an axis both compute to auto (their initial values),
// their used values are zero (i.e., the boxes stay in their original position in that axis).
used_start = 0;
used_end = 0;
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
} else if (computed_first.is_auto() || computed_second.is_auto()) {
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
// If only one is auto, its used value becomes the negation of the other, and the box is shifted by the specified amount.
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
if (computed_first.is_auto()) {
used_end = resolved_second;
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
used_start = -used_end;
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
} else {
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
used_start = resolved_first;
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
used_end = -used_start;
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
}
} else {
// If neither is auto, the position is over-constrained; (with respect to the writing mode of its containing block)
// the computed end side value is ignored, and its used value becomes the negation of the start side.
LibWeb: Don't use weird resolved() for insets in FormattingContext
2023-05-06 17:25:38 +02:00
used_start = resolved_first;
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
used_end = -used_start;
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
}
};
LibWeb: Rename FormattingState::ensure() -> get_mutable() This makes it much more obvious what the difference between get() and get_mutable() is.
2022-02-21 17:42:09 +01:00
auto& box_state = m_state.get_mutable(box);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
auto const& computed_values = box.computed_values();
LibWeb: Resolve top/bottom inset properties for position:relative This patch reimplements inset property resolution based on the new CSS Positioned Layout specification. Nothing should change for left/right insets, but we gain support for top/bottom. :^)
2022-03-27 16:07:19 +02:00
// FIXME: Respect the containing block's writing-mode.
LibWeb: Resolve cyclic declaration/definitions involving Length This remained undetected for a long time as HeaderCheck is disabled by default. This commit makes the following file compile again: // file: compile_me.cpp #include <LibWeb/CSS/GridTrackSize.h> // That's it, this was enough to cause a compilation error.
2022-09-13 17:42:39 +02:00
resolve_two_opposing_insets(computed_values.inset().left(), computed_values.inset().right(), box_state.inset_left, box_state.inset_right, containing_block_width_for(box));
resolve_two_opposing_insets(computed_values.inset().top(), computed_values.inset().bottom(), box_state.inset_top, box_state.inset_bottom, containing_block_height_for(box));
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: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// https://drafts.csswg.org/css-sizing-3/#fit-content-size
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 FormattingContext::calculate_fit_content_width(Layout::Box const& box, AvailableSpace const& 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 14:36:59 +01:00
{
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// If the available space in a given axis is definite,
// equal to clamp(min-content size, stretch-fit size, max-content size)
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
// (i.e. max(min-content size, min(max-content size, stretch-fit size))).
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
if (available_space.width.is_definite()) {
return max(calculate_min_content_width(box),
min(calculate_stretch_fit_width(box, available_space.width),
calculate_max_content_width(box)));
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: 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 17:59:46 +02:00
// When sizing under a min-content constraint, equal to the min-content size.
LibWeb: Make intrinsic heights dependent on available width After speaking with fantasai at CSSWG about this, it turns out I had misunderstood intrinsic heights. I originally believed all intrinsic sizes had to be computed with no influence from the surrounding context. As it turns out, intrinsic heights *are* influenced by the available width, since it's needed to determine where lines break. The APIs for calculating min-content and max-content heights now take the available width as inputs. This instantly improves layout in many cases where we'd previously make things way too wide.
2022-10-03 23:37:38 +02:00
if (available_space.width.is_min_content())
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 17:59:46 +02:00
return calculate_min_content_width(box);
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// Otherwise, equal to the max-content size in that axis.
return calculate_max_content_width(box);
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: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// https://drafts.csswg.org/css-sizing-3/#fit-content-size
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 FormattingContext::calculate_fit_content_height(Layout::Box const& box, AvailableSpace const& 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 14:36:59 +01:00
{
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// If the available space in a given axis is definite,
// equal to clamp(min-content size, stretch-fit size, max-content size)
// (i.e. max(min-content size, min(max-content size, stretch-fit size))).
if (available_space.height.is_definite()) {
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return max(calculate_min_content_height(box, available_space.width.to_px_or_zero()),
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
min(calculate_stretch_fit_height(box, available_space.height),
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
calculate_max_content_height(box, available_space.width.to_px_or_zero())));
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02: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 17:59:46 +02:00
// When sizing under a min-content constraint, equal to the min-content size.
LibWeb: Make intrinsic heights dependent on available width After speaking with fantasai at CSSWG about this, it turns out I had misunderstood intrinsic heights. I originally believed all intrinsic sizes had to be computed with no influence from the surrounding context. As it turns out, intrinsic heights *are* influenced by the available width, since it's needed to determine where lines break. The APIs for calculating min-content and max-content heights now take the available width as inputs. This instantly improves layout in many cases where we'd previously make things way too wide.
2022-10-03 23:37:38 +02:00
if (available_space.height.is_min_content())
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return calculate_min_content_height(box, available_space.width.to_px_or_zero());
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 17:59:46 +02:00
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// Otherwise, equal to the max-content size in that axis.
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return calculate_max_content_height(box, available_space.width.to_px_or_zero());
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: Fix calculating the intrinsic height of a box For computing height in FormattingContext::calculate_intrinsic_sizes we were calling into BlockFormattingContext::compute_theoretical_height which will check if the CSS height property was defined and calculate the height based on that instead of calculating the intrinsic height This patch adds a new function calculate_intrinsic_height, which will call into compute_auto_height_for_block_level_element for a block element, or into compute_height_for_replaced_element for a replaced element.
2022-03-30 19:44:18 +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
CSSPixels FormattingContext::calculate_min_content_width(Layout::Box const& box) const
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-08 00:40:53 +02:00
{
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (box.has_natural_width())
return *box.natural_width();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
auto& root_state = m_state.m_root;
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
if (cache.min_content_width.has_value())
return *cache.min_content_width;
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 throwaway_state(&m_state);
LibWeb: Set up both containing block sizes before intrinsic sizing When calculating e.g the min-content height of some box, we would only set its containing block's height to 0 in the temporary formatting state. The containing block width was not touched at all. This patch aims to do a bit better by resolving indefinite containing block sizes to INFINITY before performing intrinsic sizing. We should probably also find a way to resolve definite containing block sizes, but I'll leave that for our future selves.
2022-07-12 02:17:17 +02:00
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
auto& box_state = throwaway_state.get_mutable(box);
box_state.width_constraint = SizeConstraint::MinContent;
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
box_state.set_indefinite_content_width();
box_state.set_indefinite_content_height();
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: 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-11 01:03:02 +02:00
auto context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, LayoutMode::IntrinsicSizing, box);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
if (!context) {
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-11 01:03:02 +02:00
context = make<BlockFormattingContext>(throwaway_state, LayoutMode::IntrinsicSizing, verify_cast<BlockContainer>(box), nullptr);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
}
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
auto available_width = AvailableSize::make_min_content();
auto available_height = AvailableSize::make_indefinite();
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-11 01:03:02 +02:00
context->run(AvailableSpace(available_width, available_height));
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
LibWeb: Let FormattingContext decide the automatic width of its root Instead of special-casing FlexFormattingContext in the intrinsic sizing layout helpers, add FormattingContext::automatic_content_width() and let each context subclass decide what that means. No behavior change here, just moving this responsibility.
2023-03-19 09:57:31 +01:00
cache.min_content_width = context->automatic_content_width();
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
LibWeb/Layout: Replace `isfinite()` with `might_be_saturated()` Since we switched to using fixed-point math for CSSPixels, it cannot represent infinite values, so we need to check if the value is saturated instead.
2023-08-17 17:11:04 +02:00
if (cache.min_content_width->might_be_saturated()) {
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
// HACK: If layout calculates a non-finite result, something went wrong. Force it to zero and log a little whine.
dbgln("FIXME: Calculated non-finite min-content width for {}", box.debug_description());
cache.min_content_width = 0;
}
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
return *cache.min_content_width;
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-08 00:40:53 +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
CSSPixels FormattingContext::calculate_max_content_width(Layout::Box const& box) const
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-08 00:40:53 +02:00
{
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (box.has_natural_width())
return *box.natural_width();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
auto& root_state = m_state.m_root;
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
if (cache.max_content_width.has_value())
return *cache.max_content_width;
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 throwaway_state(&m_state);
LibWeb: Set up both containing block sizes before intrinsic sizing When calculating e.g the min-content height of some box, we would only set its containing block's height to 0 in the temporary formatting state. The containing block width was not touched at all. This patch aims to do a bit better by resolving indefinite containing block sizes to INFINITY before performing intrinsic sizing. We should probably also find a way to resolve definite containing block sizes, but I'll leave that for our future selves.
2022-07-12 02:17:17 +02:00
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
auto& box_state = throwaway_state.get_mutable(box);
box_state.width_constraint = SizeConstraint::MaxContent;
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
box_state.set_indefinite_content_width();
box_state.set_indefinite_content_height();
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: 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-11 01:03:02 +02:00
auto context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, LayoutMode::IntrinsicSizing, box);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
if (!context) {
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-11 01:03:02 +02:00
context = make<BlockFormattingContext>(throwaway_state, LayoutMode::IntrinsicSizing, verify_cast<BlockContainer>(box), nullptr);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
}
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
auto available_width = AvailableSize::make_max_content();
auto available_height = AvailableSize::make_indefinite();
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-11 01:03:02 +02:00
context->run(AvailableSpace(available_width, available_height));
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
LibWeb: Let FormattingContext decide the automatic width of its root Instead of special-casing FlexFormattingContext in the intrinsic sizing layout helpers, add FormattingContext::automatic_content_width() and let each context subclass decide what that means. No behavior change here, just moving this responsibility.
2023-03-19 09:57:31 +01:00
cache.max_content_width = context->automatic_content_width();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb/Layout: Replace `isfinite()` with `might_be_saturated()` Since we switched to using fixed-point math for CSSPixels, it cannot represent infinite values, so we need to check if the value is saturated instead.
2023-08-17 17:11:04 +02:00
if (cache.max_content_width->might_be_saturated()) {
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
// HACK: If layout calculates a non-finite result, something went wrong. Force it to zero and log a little whine.
dbgln("FIXME: Calculated non-finite max-content width for {}", box.debug_description());
cache.max_content_width = 0;
}
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
return *cache.max_content_width;
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-08 00:40:53 +02:00
}
LibWeb: Make min-content height equivalent to max-content as appropriate Per CSS-SIZING-3, the min-content block size should be equivalent to the max-content block size for some boxes. Honoring this gives more correct results, and avoids unnecessary work in many cases since the cached max-content size can be reused.
2023-01-23 17:24:56 +01:00
// https://www.w3.org/TR/css-sizing-3/#min-content-block-size
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
CSSPixels FormattingContext::calculate_min_content_height(Layout::Box const& box, CSSPixels width) const
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-08 00:40:53 +02:00
{
LibWeb: Make min-content height equivalent to max-content as appropriate Per CSS-SIZING-3, the min-content block size should be equivalent to the max-content block size for some boxes. Honoring this gives more correct results, and avoids unnecessary work in many cases since the cached max-content size can be reused.
2023-01-23 17:24:56 +01:00
// For block containers, tables, and inline boxes, this is equivalent to the max-content block size.
LibWeb: Remove Layout::TableBox Solves conflict in layout tree "type system" when elements <label> (or <button>) can't have `display: table` because Box can't be Layout::Label (or Layout::ButtonBox) and Layout::TableBox at the same time.
2023-05-29 14:11:19 +03:00
if (box.is_block_container() || box.display().is_table_inside())
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return calculate_max_content_height(box, width);
LibWeb: Make min-content height equivalent to max-content as appropriate Per CSS-SIZING-3, the min-content block size should be equivalent to the max-content block size for some boxes. Honoring this gives more correct results, and avoids unnecessary work in many cases since the cached max-content size can be reused.
2023-01-23 17:24:56 +01:00
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (box.has_natural_height())
return *box.natural_height();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
auto get_cache_slot = [&]() -> Optional<CSSPixels>* {
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
auto& root_state = m_state.m_root;
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return &cache.min_content_height.ensure(width);
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
};
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
if (auto* cache_slot = get_cache_slot(); cache_slot && cache_slot->has_value())
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
return cache_slot->value();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02: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 throwaway_state(&m_state);
LibWeb: Set up both containing block sizes before intrinsic sizing When calculating e.g the min-content height of some box, we would only set its containing block's height to 0 in the temporary formatting state. The containing block width was not touched at all. This patch aims to do a bit better by resolving indefinite containing block sizes to INFINITY before performing intrinsic sizing. We should probably also find a way to resolve definite containing block sizes, but I'll leave that for our future selves.
2022-07-12 02:17:17 +02:00
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
auto& box_state = throwaway_state.get_mutable(box);
box_state.height_constraint = SizeConstraint::MinContent;
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
box_state.set_indefinite_content_height();
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
box_state.set_content_width(width);
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: 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-11 01:03:02 +02:00
auto context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, LayoutMode::IntrinsicSizing, box);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
if (!context) {
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-11 01:03:02 +02:00
context = make<BlockFormattingContext>(throwaway_state, LayoutMode::IntrinsicSizing, verify_cast<BlockContainer>(box), nullptr);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
}
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02: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-11 01:03:02 +02:00
context->run(AvailableSpace(AvailableSize::make_definite(width), AvailableSize::make_min_content()));
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
auto min_content_height = context->automatic_content_height();
LibWeb/Layout: Replace `isfinite()` with `might_be_saturated()` Since we switched to using fixed-point math for CSSPixels, it cannot represent infinite values, so we need to check if the value is saturated instead.
2023-08-17 17:11:04 +02:00
if (min_content_height.might_be_saturated()) {
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
// HACK: If layout calculates a non-finite result, something went wrong. Force it to zero and log a little whine.
dbgln("FIXME: Calculated non-finite min-content height for {}", box.debug_description());
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
min_content_height = 0;
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
}
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
if (auto* cache_slot = get_cache_slot()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
*cache_slot = min_content_height;
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
}
return min_content_height;
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-08 00:40:53 +02:00
}
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
CSSPixels FormattingContext::calculate_max_content_height(Layout::Box const& box, CSSPixels width) const
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-08 00:40:53 +02:00
{
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
if (box.has_preferred_aspect_ratio())
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 17:33:58 -05:00
return width / *box.preferred_aspect_ratio();
LibWeb: Use intrinsic aspect ratio when calculating max content height
2023-04-03 18:26:13 -03:00
LibWeb: Move "natural size" concept into Layout::Box Having this here instead of in ReplacedBox means we can access it when figuring out what the "preferred aspect ratio" is. There's some inconsistency between specs about what this is called, but they're moving towards referring to this as "natural width/height/ aspect-ratio", so let's copy that terminology.
2023-06-08 15:56:28 +01:00
if (box.has_natural_height())
return *box.natural_height();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
auto get_cache_slot = [&]() -> Optional<CSSPixels>* {
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
auto& root_state = m_state.m_root;
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
return &cache.max_content_height.ensure(width);
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
};
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
if (auto* cache_slot = get_cache_slot(); cache_slot && cache_slot->has_value())
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
return cache_slot->value();
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02: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 throwaway_state(&m_state);
LibWeb: Set up both containing block sizes before intrinsic sizing When calculating e.g the min-content height of some box, we would only set its containing block's height to 0 in the temporary formatting state. The containing block width was not touched at all. This patch aims to do a bit better by resolving indefinite containing block sizes to INFINITY before performing intrinsic sizing. We should probably also find a way to resolve definite containing block sizes, but I'll leave that for our future selves.
2022-07-12 02:17:17 +02:00
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
auto& box_state = throwaway_state.get_mutable(box);
box_state.height_constraint = SizeConstraint::MaxContent;
LibWeb: Make box content sizes indefinite before intrinsic sizing When calculating the intrinsic width of a box, we now make its content width & height indefinite before entering the intrinsic sizing layout. This ensures that any geometry assigned to the box by its parent formatting context is ignored. For intrinsic heights, we only make the content height indefinite. This is because used content width is a valid (but optional) input to intrinsic height calculation.
2023-03-27 14:12:05 +02:00
box_state.set_indefinite_content_height();
LibWeb: Forbid usage of indefinite width in calculate_min{max}_height Changing `calculate_min_content_heigh()` and `calculate_min_content_heigh()` to accept width as `CSSPixels`, instead of `AvailableSize` that might be indefinite, makes it more explicit that width is supposed to be known by the time height is measured. This change has a bit of collateral damage which is rows height calculation regression in `table/inline-table-width` that worked before by accident.
2023-08-12 15:17:17 +02:00
box_state.set_content_width(width);
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: 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-11 01:03:02 +02:00
auto context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, LayoutMode::IntrinsicSizing, box);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
if (!context) {
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-11 01:03:02 +02:00
context = make<BlockFormattingContext>(throwaway_state, LayoutMode::IntrinsicSizing, verify_cast<BlockContainer>(box), nullptr);
LibWeb: Allow calculating intrinsic sizes of non-FC-roots In order to support intrinsic size keywords (such as fit-content), we need to be able to calculate the intrinsic sizes of any element, not just those that form their own formatting context. When a non-FC-root element is passed to calculate_some_intrinsic_size(), we now create a synthetic BFC to handle sizing of them.
2023-05-26 18:58:33 +02:00
}
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02: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-11 01:03:02 +02:00
context->run(AvailableSpace(AvailableSize::make_definite(width), AvailableSize::make_max_content()));
LibWeb: Get rid of FormattingContext::run_intrinsic_sizing() Now that we have AvailableSpace, it's actually quite convenient to simply set up the available space and call run() with that directly.
2022-10-03 20:52:28 +02:00
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
auto max_content_height = context->automatic_content_height();
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
LibWeb/Layout: Replace `isfinite()` with `might_be_saturated()` Since we switched to using fixed-point math for CSSPixels, it cannot represent infinite values, so we need to check if the value is saturated instead.
2023-08-17 17:11:04 +02:00
if (max_content_height.might_be_saturated()) {
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
// HACK: If layout calculates a non-finite result, something went wrong. Force it to zero and log a little whine.
dbgln("FIXME: Calculated non-finite max-content height for {}", box.debug_description());
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
max_content_height = 0;
}
LibWeb: Re-lookup the intrinsic sizing cache slot after doing the layout It's not safe to hold on to a pointer to the cache slot across layout work, since the nested layout may end up causing new entries to get added to the cache, potentially invalidating a cache slot pointer.
2023-05-06 15:47:58 +02:00
if (auto* cache_slot = get_cache_slot()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
*cache_slot = max_content_height;
LibWeb: Add safety mechanism to guard against non-finite layout sizes Due to some yet-to-be-found bug(s) in intrinsic sizing, we can sometimes end up deciding that some box has a non-finite intrinsic size. This will create unpleasant results, and may lead to some layout algorithms looping infinitely, so this patch adds a safeguard where we simply turn non-finite intrinsic sizes into zero (and complain a little bit in the debug log.)
2022-07-11 23:53:52 +02:00
}
LibWeb: Only perform the requested form of intrinsic size calculation Before, querying any of the four intrinsic sizes would cause us to calculate all of them (the four being min-content width/height, and max-content width/height). Now, the helper functions only calculate the specific intrinsic size requested. It's then cached at the root formatting context level, so that it's never calculated twice within the same layout pass.
2022-07-08 12:44:49 +02:00
LibWeb: Split intrinsic heights cache based on available width Now that intrinsic heights (correctly) depend on the amount of available width, we can't just cache the first calculated min-content and max-content heights and reuse it without thinking. Instead, we have to cache three pairs: - min-content & max-content height with definite available width - min-content & max-content height with min-content available width - min-content & max-content height with max-content available width There might be some more elegant way of solving this, but basically this makes the cache work correctly when someone's containing block is being sized under a width constraint.
2022-10-08 20:27:54 +02:00
return max_content_height;
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-08 00:40:53 +02:00
}
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
CSSPixels FormattingContext::calculate_inner_width(Layout::Box const& box, AvailableSize const& available_width, CSS::Size const& width) const
LibWeb: Support box-sizing in BFC Add support for box-sizing in block formatting context, support for Flex Formatting Context and Grid Formatting Context is missing
2022-11-21 22:17:24 +03:00
{
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
VERIFY(!width.is_auto());
LibWeb: Treat non-finite containing block width as zero for percentages Fixes an assertion when loading https://bun.sh/
2023-07-01 08:27:47 +02:00
auto width_of_containing_block = available_width.to_px_or_zero();
LibWeb: Support fit-content width for block-level boxes
2023-05-26 19:04:01 +02:00
if (width.is_fit_content()) {
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
return calculate_fit_content_width(box, AvailableSpace { available_width, AvailableSize::make_indefinite() });
LibWeb: Support fit-content width for block-level boxes
2023-05-26 19:04:01 +02:00
}
LibWeb: Support `max-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 18:18:34 +02:00
if (width.is_max_content()) {
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
return calculate_max_content_width(box);
LibWeb: Support `max-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 18:18:34 +02:00
}
LibWeb: Support `min-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 18:24:55 +02:00
if (width.is_min_content()) {
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
return calculate_min_content_width(box);
LibWeb: Support `min-content` for `width`, `min-width` and `max-width` We're gonna need to handle this in many more places, this patch only adds it to calculate_inner_width().
2023-05-28 18:24:55 +02: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
auto& computed_values = box.computed_values();
if (computed_values.box_sizing() == CSS::BoxSizing::BorderBox) {
LibWeb: Add `Length::resolved()` overload for CSSPixels Since we always pass the px value as an argument to resolved(), we can pass it directly as CSSPixels instead of wrapping it in Length. This approach allows us to avoid converting to a double, resulting in fewer precision issues.
2023-08-29 18:57:09 +02:00
auto const padding_left = computed_values.padding().left().resolved(box, width_of_containing_block);
auto const padding_right = computed_values.padding().right().resolved(box, width_of_containing_block);
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
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
auto inner_width = width.to_px(box, width_of_containing_block)
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
- computed_values.border_left().width
- padding_left.to_px(box)
- computed_values.border_right().width
- padding_right.to_px(box);
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
return max(inner_width, 0);
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
}
LibWeb: Return CSSPixels from `calculate_inner_width()` Initially, this function was made to return CSS::Length because some of its callers were expecting it to ignore "auto" width on input and return it as is. Instead, let's just forbid using "auto" for input width and always return CSSPixels.
2024-01-07 05:24:09 +01:00
return width.resolved(box, width_of_containing_block).to_px(box);
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
}
LibWeb: Return CSSPixels from `calculate_inner_height()` Similar to calculate_inner_width(), let's make the caller responsible for handling "auto" instead of returning the input height as is when when it cannot be resolved.
2024-01-07 05:46:36 +01:00
CSSPixels FormattingContext::calculate_inner_height(Layout::Box const& box, AvailableSize const&, CSS::Size const& height) const
LibWeb: Support box-sizing in BFC Add support for box-sizing in block formatting context, support for Flex Formatting Context and Grid Formatting Context is missing
2022-11-21 22:17:24 +03:00
{
LibWeb: Return CSSPixels from `calculate_inner_height()` Similar to calculate_inner_width(), let's make the caller responsible for handling "auto" instead of returning the input height as is when when it cannot be resolved.
2024-01-07 05:46:36 +01:00
VERIFY(!height.is_auto());
LibWeb: Use padding box of containing block to resolve % height size From CSS-POSITION-3 <https://www.w3.org/TR/css-position-3/#def-cb> "..the containing block is formed by the padding edge of the ancestor.." Fixes crash on Acid2 test.
2023-06-18 19:18:49 +03:00
auto const* containing_block = box.non_anonymous_containing_block();
auto const& containing_block_state = m_state.get(*containing_block);
auto height_of_containing_block = containing_block_state.content_height();
LibWeb: Rename "position" enum to "positioning" The postitioning enum values are used by the position CSS property. Unfortunately, the prior naming clashes with the CSS Values-4 type named position, which will be implemented in a later commit.
2023-10-27 15:17:36 +02:00
if (box.computed_values().position() == CSS::Positioning::Absolute) {
LibWeb: Use padding box of containing block to resolve % height size From CSS-POSITION-3 <https://www.w3.org/TR/css-position-3/#def-cb> "..the containing block is formed by the padding edge of the ancestor.." Fixes crash on Acid2 test.
2023-06-18 19:18:49 +03:00
// https://www.w3.org/TR/css-position-3/#def-cb
// If the box has position: absolute, then the containing block is formed by the padding edge of the ancestor
height_of_containing_block += containing_block_state.padding_top + containing_block_state.padding_bottom;
}
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
auto& computed_values = box.computed_values();
if (computed_values.box_sizing() == CSS::BoxSizing::BorderBox) {
LibWeb: Add `Length::resolved()` overload for CSSPixels Since we always pass the px value as an argument to resolved(), we can pass it directly as CSSPixels instead of wrapping it in Length. This approach allows us to avoid converting to a double, resulting in fewer precision issues.
2023-08-29 18:57:09 +02:00
auto width_of_containing_block = containing_block_width_for(box);
LibWeb: Fix bogus percentage vertical padding with box-sizing:border-box The padding-top and padding-bottom properties are relative to the *width* of the containing block, not the height. It's funny how we keep making this same mistake again and again. :^)
2023-03-10 11:32:29 +01:00
LibWeb: Remove early resolve to auto while calculating border-box width `Length::resolved(Node&)` transforms infinite values to "auto". Following transformations: Infinite (Length) -> "auto" -> 0 (px) cause border-box width to be resolved in zero when it should be inf px. Removing `Length::resolved(Node&)` makes it work right: Infinite (Length) -> Infinite (px) Fixes #18649
2023-05-05 09:45:19 +03:00
auto const padding_top = computed_values.padding().top().resolved(box, width_of_containing_block);
auto const padding_bottom = computed_values.padding().bottom().resolved(box, width_of_containing_block);
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
LibWeb: Use the new to_px() helpers in CSS, SVG and layout code There should be no behavior change from this, only slightly less verbosity. :^)
2023-05-06 16:34:55 +02:00
auto inner_height = height.to_px(box, height_of_containing_block)
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
- computed_values.border_top().width
- padding_top.to_px(box)
- computed_values.border_bottom().width
- padding_bottom.to_px(box);
LibWeb: Return CSSPixels from `calculate_inner_height()` Similar to calculate_inner_width(), let's make the caller responsible for handling "auto" instead of returning the input height as is when when it cannot be resolved.
2024-01-07 05:46:36 +01:00
return max(inner_height, 0);
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
}
LibWeb: Return CSSPixels from `calculate_inner_height()` Similar to calculate_inner_width(), let's make the caller responsible for handling "auto" instead of returning the input height as is when when it cannot be resolved.
2024-01-07 05:46:36 +01:00
return height.resolved(box, height_of_containing_block).to_px(box);
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
}
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
CSSPixels FormattingContext::containing_block_width_for(NodeWithStyleAndBoxModelMetrics const& node) 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: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
auto const& containing_block_state = m_state.get(*node.containing_block());
auto const& node_state = m_state.get(node);
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: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
switch (node_state.width_constraint) {
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
case SizeConstraint::MinContent:
return 0;
case SizeConstraint::MaxContent:
LibWeb/Layout: Replace `INFINITY` with `CSSPixels::min()` or `max()`
2023-08-17 17:26:31 +02:00
return CSSPixels::max();
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
case SizeConstraint::None:
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
return containing_block_state.content_width();
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
}
VERIFY_NOT_REACHED();
}
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
CSSPixels FormattingContext::containing_block_height_for(NodeWithStyleAndBoxModelMetrics const& node) 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: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
auto const& containing_block_state = m_state.get(*node.containing_block());
auto const& node_state = m_state.get(node);
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: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
switch (node_state.height_constraint) {
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
case SizeConstraint::MinContent:
return 0;
case SizeConstraint::MaxContent:
LibWeb/Layout: Replace `INFINITY` with `CSSPixels::min()` or `max()`
2023-08-17 17:26:31 +02:00
return CSSPixels::max();
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
case SizeConstraint::None:
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
return containing_block_state.content_height();
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
}
VERIFY_NOT_REACHED();
}
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
AvailableSize FormattingContext::containing_block_width_as_available_size(NodeWithStyleAndBoxModelMetrics const& node) const
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
{
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
auto const& containing_block_state = m_state.get(*node.containing_block());
auto const& node_state = m_state.get(node);
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
switch (node_state.width_constraint) {
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
case SizeConstraint::MinContent:
return AvailableSize::make_min_content();
case SizeConstraint::MaxContent:
return AvailableSize::make_max_content();
case SizeConstraint::None:
return AvailableSize::make_definite(containing_block_state.content_width());
}
VERIFY_NOT_REACHED();
}
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
AvailableSize FormattingContext::containing_block_height_as_available_size(NodeWithStyleAndBoxModelMetrics const& node) const
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
{
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
auto const& containing_block_state = m_state.get(*node.containing_block());
auto const& node_state = m_state.get(node);
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
LibWeb: Make containing_block_{width,height}_for(...) take non-box nodes There's no reason for this API to require a Layout::Box as input. Any node that can have layout state is welcome, so this patch makes it take NodeWithStyleAndBoxModelMetrics.
2023-08-15 09:30:13 +02:00
switch (node_state.height_constraint) {
LibWeb: Resolve flex item percentages against used flex container sizes Once we've resolved the used flex item width & height, we should allow percentage flex item sizes to resolve against them instead of forcing flex items to always treat percentages as auto while doing intrinsic sizing layout. Regressed in 8dd489da61362738a39ec938732e3d054ff5da8b.
2023-07-17 21:19:33 +02:00
case SizeConstraint::MinContent:
return AvailableSize::make_min_content();
case SizeConstraint::MaxContent:
return AvailableSize::make_max_content();
case SizeConstraint::None:
return AvailableSize::make_definite(containing_block_state.content_height());
}
VERIFY_NOT_REACHED();
}
LibWeb: Add a helper for calculating the stretch-fit width of a box
2022-09-26 15:41:22 +02:00
// https://drafts.csswg.org/css-sizing-3/#stretch-fit-size
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
CSSPixels FormattingContext::calculate_stretch_fit_width(Box const& box, AvailableSize const& available_width) const
LibWeb: Add a helper for calculating the stretch-fit width of a box
2022-09-26 15:41:22 +02:00
{
// The size a box would take if its outer size filled the available space in the given axis;
// in other words, the stretch fit into the available space, if that is definite.
LibWeb: Make stretch-fit return 0 when the available size is indefinite The spec says the result of this algorithm is undefined in such cases, and it appears that other engines yield a zero size. More importantly, this prevents us from leaking a non-finite value into the layout tree.
2023-06-13 06:43:19 +02:00
LibWeb: Add a helper for calculating the stretch-fit width of a box
2022-09-26 15:41:22 +02:00
// Undefined if the available space is indefinite.
LibWeb: Make stretch-fit return 0 when the available size is indefinite The spec says the result of this algorithm is undefined in such cases, and it appears that other engines yield a zero size. More importantly, this prevents us from leaking a non-finite value into the layout tree.
2023-06-13 06:43:19 +02:00
if (!available_width.is_definite())
return 0;
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
auto const& box_state = m_state.get(box);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
return available_width.to_px_or_zero()
LibWeb: Add a helper for calculating the stretch-fit width of a box
2022-09-26 15:41:22 +02:00
- box_state.margin_left
- box_state.margin_right
- box_state.padding_left
- box_state.padding_right
- box_state.border_left
- box_state.border_right;
}
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
// https://drafts.csswg.org/css-sizing-3/#stretch-fit-size
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
CSSPixels FormattingContext::calculate_stretch_fit_height(Box const& box, AvailableSize const& available_height) const
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
{
// The size a box would take if its outer size filled the available space in the given axis;
// in other words, the stretch fit into the available space, if that is definite.
// Undefined if the available space is indefinite.
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
auto const& box_state = m_state.get(box);
LibWeb: Replace to_px() with to_px_or_zero() in FormattingContext to_px() usage should be avoided because it might leak saturated (infinite) values into layout calculations.
2023-08-12 18:29:43 +02:00
return available_height.to_px_or_zero()
LibWeb: Implement CSS fit-content algorithm precisely as spec says We were using the available space in place of the stretch-fit size. This was an oversight, and this patch fixes that. It's very possible that this will uncover broken behavior elsewhere.
2022-10-14 15:09:40 +02:00
- box_state.margin_top
- box_state.margin_bottom
- box_state.padding_top
- box_state.padding_bottom
- box_state.border_top
- box_state.border_bottom;
}
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
bool FormattingContext::should_treat_width_as_auto(Box const& box, AvailableSpace const& available_space)
{
LibWeb: Treat width: {min,max,fit}-content as auto if ratio unresolvable This appears to match other engines.
2024-06-23 16:00:20 +02:00
auto const& computed_width = box.computed_values().width();
if (computed_width.is_auto())
LibWeb: Resolve cyclic % against 0 when available size is min-content This fixes an issue where replaced elements with cyclic percentage width would make an oversized min-content contribution to its container.
2023-06-08 12:56:34 +02:00
return true;
LibWeb: Treat width: {min,max,fit}-content as auto if ratio unresolvable This appears to match other engines.
2024-06-23 16:00:20 +02:00
if (computed_width.contains_percentage()) {
LibWeb: Resolve cyclic % against 0 when available size is min-content This fixes an issue where replaced elements with cyclic percentage width would make an oversized min-content contribution to its container.
2023-06-08 12:56:34 +02:00
if (available_space.width.is_max_content())
return true;
if (available_space.width.is_indefinite())
return true;
}
LibWeb: Treat width: {min,max,fit}-content as auto if ratio unresolvable This appears to match other engines.
2024-06-23 16:00:20 +02:00
// AD-HOC: If the box has a preferred aspect ratio and no natural height,
// we treat the width as auto, since it can't be resolved through the ratio.
if (computed_width.is_min_content() || computed_width.is_max_content() || computed_width.is_fit_content()) {
if (box.has_preferred_aspect_ratio() && !box.has_natural_height())
return true;
}
LibWeb: Resolve cyclic % against 0 when available size is min-content This fixes an issue where replaced elements with cyclic percentage width would make an oversized min-content contribution to its container.
2023-06-08 12:56:34 +02:00
return false;
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
}
bool FormattingContext::should_treat_height_as_auto(Box const& box, AvailableSpace const& available_space)
{
LibWeb: Accept height: {min,max,fit}-content And treat them as "auto" for now, per CSS-SIZING-3, with a FIXME about supporting more layout directions. This fixes an issue on MDN where `height: max-content` was not overriding height from non-CSS presentational hints.
2023-08-20 18:25:54 +02:00
auto computed_height = box.computed_values().height();
if (computed_height.is_auto())
return true;
// https://www.w3.org/TR/css-sizing-3/#valdef-width-min-content
// https://www.w3.org/TR/css-sizing-3/#valdef-width-max-content
// https://www.w3.org/TR/css-sizing-3/#valdef-width-fit-content
// For a box’s block size, unless otherwise specified, this is equivalent to its automatic size.
// FIXME: If height is not the block axis size, then we should be concerned with the width instead.
if (computed_height.is_min_content() || computed_height.is_max_content() || computed_height.is_fit_content())
LibWeb: Resolve cyclic % against 0 when available size is min-content This fixes an issue where replaced elements with cyclic percentage width would make an oversized min-content contribution to its container.
2023-06-08 12:56:34 +02:00
return true;
LibWeb: Accept height: {min,max,fit}-content And treat them as "auto" for now, per CSS-SIZING-3, with a FIXME about supporting more layout directions. This fixes an issue on MDN where `height: max-content` was not overriding height from non-CSS presentational hints.
2023-08-20 18:25:54 +02:00
LibWeb: Resolve cyclic % against 0 when available size is min-content This fixes an issue where replaced elements with cyclic percentage width would make an oversized min-content contribution to its container.
2023-06-08 12:56:34 +02:00
if (box.computed_values().height().contains_percentage()) {
if (available_space.height.is_max_content())
return true;
if (available_space.height.is_indefinite())
return true;
}
return false;
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
}
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 FormattingContext::can_skip_is_anonymous_text_run(Box& box)
{
if (box.is_anonymous() && !box.is_generated() && !box.first_child_of_type<BlockContainer>()) {
bool contains_only_white_space = true;
box.for_each_in_subtree([&](auto const& node) {
LibWeb: Port CharacterData from DeprecatedString to String The existing implementation has some pre-existing issues where it is incorrectly assumes that byte offsets are given through the IDL instead of UTF-16 code units. While making these changes, leave some FIXMEs for that.
2023-09-07 21:36:05 +12:00
if (!is<TextNode>(node) || !static_cast<TextNode const&>(node).dom_node().data().bytes_as_string_view().is_whitespace()) {
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
contains_only_white_space = false;
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Break;
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
}
LibWeb: Use `TraversalDecision` for multi level Node traversal methods This adds the `SkipChildrenAndContinue` option, where traversal continues but child nodes are not included.
2024-05-04 14:47:04 +01:00
return TraversalDecision::Continue;
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
});
if (contains_only_white_space)
return true;
}
return false;
}
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
CSSPixelRect FormattingContext::absolute_content_rect(Box const& box) const
{
auto const& box_state = m_state.get(box);
CSSPixelRect rect { box_state.offset, { box_state.content_width(), box_state.content_height() } };
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
for (auto* block = box_state.containing_block_used_values(); block; block = block->containing_block_used_values())
rect.translate_by(block->offset);
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
return rect;
}
LibWeb: Derive box baseline from last child *with line boxes* Before this change, we always derived a box's baseline from its last child, even if the last child didn't have any line boxes inside. This caused baselines to slip further down vertically than expected. There are more baseline alignment issues to fix, but this one was responsible for a fair chunk of trouble. :^)
2023-07-25 10:58:11 +02:00
Box const* FormattingContext::box_child_to_derive_baseline_from(Box const& box) const
{
LibWeb: Derive baseline from rightmost descendant Make the existing algorithm recursive, accounting for boxes which contain line boxes indirectly. Fixes some button alignment issues on Wikipedia.
2023-08-20 08:50:28 +00:00
if (!box.has_children() || box.children_are_inline())
return nullptr;
LibWeb: Derive box baseline from last child *with line boxes* Before this change, we always derived a box's baseline from its last child, even if the last child didn't have any line boxes inside. This caused baselines to slip further down vertically than expected. There are more baseline alignment issues to fix, but this one was responsible for a fair chunk of trouble. :^)
2023-07-25 10:58:11 +02:00
// To find the baseline of a box, we first look for the last in-flow child with at least one line box.
auto const* last_box_child = box.last_child_of_type<Box>();
for (Node const* child = last_box_child; child; child = child->previous_sibling()) {
if (!child->is_box())
continue;
auto& child_box = static_cast<Box const&>(*child);
LibWeb: Derive baseline from rightmost descendant Make the existing algorithm recursive, accounting for boxes which contain line boxes indirectly. Fixes some button alignment issues on Wikipedia.
2023-08-20 08:50:28 +00:00
if (!child_box.is_out_of_flow(*this) && !m_state.get(child_box).line_boxes.is_empty()) {
return &child_box;
}
auto box_child_to_derive_baseline_from_candidate = box_child_to_derive_baseline_from(child_box);
if (box_child_to_derive_baseline_from_candidate)
return box_child_to_derive_baseline_from_candidate;
LibWeb: Derive box baseline from last child *with line boxes* Before this change, we always derived a box's baseline from its last child, even if the last child didn't have any line boxes inside. This caused baselines to slip further down vertically than expected. There are more baseline alignment issues to fix, but this one was responsible for a fair chunk of trouble. :^)
2023-07-25 10:58:11 +02:00
}
LibWeb: Only derive baseline from children with a non-empty line box If none of the box children have a baseline set, the bottom margin edge of the box is used as the baseline.
2023-07-28 09:58:01 -04:00
// None of the children has a line box.
return nullptr;
LibWeb: Derive box baseline from last child *with line boxes* Before this change, we always derived a box's baseline from its last child, even if the last child didn't have any line boxes inside. This caused baselines to slip further down vertically than expected. There are more baseline alignment issues to fix, but this one was responsible for a fair chunk of trouble. :^)
2023-07-25 10:58:11 +02: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
CSSPixels FormattingContext::box_baseline(Box const& box) const
{
auto const& box_state = m_state.get(box);
// https://www.w3.org/TR/CSS2/visudet.html#propdef-vertical-align
auto const& vertical_align = box.computed_values().vertical_align();
if (vertical_align.has<CSS::VerticalAlign>()) {
switch (vertical_align.get<CSS::VerticalAlign>()) {
case CSS::VerticalAlign::Top:
// Top: Align the top of the aligned subtree with the top of the line box.
return box_state.border_box_top();
LibWeb: Improve support for 'vertical-align: middle' This rebaselines a few table-related layout tests since our default stylesheet applies 'vertical-align: middle' to a few table-related elements.
2024-02-28 19:45:25 +04:00
case CSS::VerticalAlign::Middle:
// Align the vertical midpoint of the box with the baseline of the parent box plus half the x-height of the parent.
return box_state.content_height() / 2 + CSSPixels::nearest_value_for(box.containing_block()->first_available_font().pixel_metrics().x_height / 2);
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
case CSS::VerticalAlign::Bottom:
// Bottom: Align the bottom of the aligned subtree with the bottom of the line box.
return box_state.content_height() + box_state.margin_box_top();
case CSS::VerticalAlign::TextTop:
// TextTop: Align the top of the box with the top of the parent's content area (see 10.6.1).
LibWeb: Store computed CSS font size as `CSSPixels` The value is originally set using a `CSSPixels` value converted to double, then when it is used it is always converted back to a `CSSPixels` again. Let's just store it as that instead.
2023-08-31 19:53:41 -05:00
return box.computed_values().font_size();
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
case CSS::VerticalAlign::TextBottom:
// TextTop: Align the bottom of the box with the bottom of the parent's content area (see 10.6.1).
LibGfx+LibWeb: Produce font cascade list in CSS font matching algorithm According to the CSS font matching algorithm specification, it is supposed to be executed for each glyph instead of each text run, as is currently done. This change partially implements this by having the font matching algorithm produce a list of fonts against which each glyph will be tested to find its suitable font. Now, it becomes possible to have per-glyph fallback fonts: if the needed glyph is not present in a font, we can check the subsequent fonts in the list.
2023-12-09 23:42:02 +01:00
return box_state.content_height() - CSSPixels::nearest_value_for(box.containing_block()->first_available_font().pixel_metrics().descent * 2);
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
default:
break;
}
}
if (!box_state.line_boxes.is_empty())
return box_state.margin_box_top() + box_state.offset.y() + box_state.line_boxes.last().baseline();
LibWeb: Derive baseline from rightmost descendant Make the existing algorithm recursive, accounting for boxes which contain line boxes indirectly. Fixes some button alignment issues on Wikipedia.
2023-08-20 08:50:28 +00:00
if (auto const* child_box = box_child_to_derive_baseline_from(box)) {
LibWeb: Propagate margin and offset when computing a box's baseline When traversing the layout tree to find an appropriate box child to derive the baseline from. Only the child's margin and offset was being applied. Now we sum each offset on the recursive call.
2024-07-15 16:07:06 +01:00
return box_state.margin_box_top() + box_state.offset.y() + box_baseline(*child_box);
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
}
LibWeb: Derive baseline from rightmost descendant Make the existing algorithm recursive, accounting for boxes which contain line boxes indirectly. Fixes some button alignment issues on Wikipedia.
2023-08-20 08:50:28 +00:00
// If none of the children have a baseline set, the bottom margin edge of the box is used.
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
return box_state.margin_box_height();
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::margin_box_rect(LayoutState::UsedValues const& used_values) const
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 10:18:34 +02:00
{
return {
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
used_values.offset.translated(-used_values.margin_box_left(), -used_values.margin_box_top()),
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
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
used_values.margin_box_left() + used_values.content_width() + used_values.margin_box_right(),
used_values.margin_box_top() + used_values.content_height() + used_values.margin_box_bottom(),
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
},
};
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::margin_box_rect(Box const& box) const
{
return margin_box_rect(m_state.get(box));
}
CSSPixelRect FormattingContext::border_box_rect(LayoutState::UsedValues const& used_values) const
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 10:18:34 +02:00
{
return {
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
used_values.offset.translated(-used_values.border_box_left(), -used_values.border_box_top()),
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
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
used_values.border_box_left() + used_values.content_width() + used_values.border_box_right(),
used_values.border_box_top() + used_values.content_height() + used_values.border_box_bottom(),
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
},
};
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::border_box_rect(Box const& box) const
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 10:18:34 +02:00
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
return border_box_rect(m_state.get(box));
}
CSSPixelRect FormattingContext::border_box_rect_in_ancestor_coordinate_space(LayoutState::UsedValues const& used_values, Box const& ancestor_box) const
{
auto rect = border_box_rect(used_values);
if (&used_values.node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
for (auto const* current = used_values.containing_block_used_values(); current; current = current->containing_block_used_values()) {
if (&current->node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
rect.translate_by(current->offset);
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
}
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::border_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box) const
{
return border_box_rect_in_ancestor_coordinate_space(m_state.get(box), ancestor_box);
}
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
CSSPixelRect FormattingContext::content_box_rect(Box const& box) const
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
return content_box_rect(m_state.get(box));
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
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::content_box_rect(LayoutState::UsedValues const& used_values) const
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 10:18:34 +02:00
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
return CSSPixelRect { used_values.offset, { used_values.content_width(), used_values.content_height() } };
}
CSSPixelRect FormattingContext::content_box_rect_in_ancestor_coordinate_space(LayoutState::UsedValues const& used_values, Box const& ancestor_box) const
{
auto rect = content_box_rect(used_values);
if (&used_values.node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
for (auto const* current = used_values.containing_block_used_values(); current; current = current->containing_block_used_values()) {
if (&current->node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
rect.translate_by(current->offset);
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
}
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::content_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box) const
LibWeb: Move layout box rect helpers into FormattingContext These are only used during layout, and always within formatting context code, so we might as well put them in FormattingContext and avoid having to pass the LayoutState around all the time.
2023-05-31 10:18:34 +02:00
{
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
return content_box_rect_in_ancestor_coordinate_space(m_state.get(box), ancestor_box);
}
CSSPixelRect FormattingContext::margin_box_rect_in_ancestor_coordinate_space(LayoutState::UsedValues const& used_values, Box const& ancestor_box) const
{
auto rect = margin_box_rect(used_values);
if (&used_values.node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
for (auto const* current = used_values.containing_block_used_values(); current; current = current->containing_block_used_values()) {
if (&current->node() == &ancestor_box)
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
return rect;
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
rect.translate_by(current->offset);
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
}
// If we get here, ancestor_box was not a containing block ancestor of `box`!
VERIFY_NOT_REACHED();
}
LibWeb: Use UsedValues containing block pointer in many FC helpers
2024-01-17 11:24:41 +01:00
CSSPixelRect FormattingContext::margin_box_rect_in_ancestor_coordinate_space(Box const& box, Box const& ancestor_box) const
{
return margin_box_rect_in_ancestor_coordinate_space(m_state.get(box), ancestor_box);
}
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& box)
{
// When a box has a preferred aspect ratio, its automatic sizes are calculated the same as for a
// replaced element with a natural aspect ratio and no natural size in that axis, see e.g. CSS2 §10
// and CSS Flexible Box Model Level 1 §9.2.
// https://www.w3.org/TR/css-sizing-4/#aspect-ratio-automatic
LibWeb: Don't use stretch-fit width for inline boxes with aspect ratio
2024-03-27 15:03:24 +01:00
if (is<ReplacedBox>(box))
return true;
if (box.has_preferred_aspect_ratio()) {
// From CSS2:
// If height and width both have computed values of auto and the element has an intrinsic ratio but no intrinsic height or width,
// then the used value of width is undefined in CSS 2.
// However, it is suggested that, if the containing block’s width does not itself depend on the replaced element’s width,
// then the used value of width is calculated from the constraint equation used for block-level, non-replaced elements in normal flow.
// AD-HOC: For inline-level boxes, we don't want to end up in a situation where we apply stretch-fit sizing,
// since that would not match other browsers. Because of that, we specifically reject this case here
// instead of allowing it to proceed.
if (box.display().is_inline_outside()
&& box.computed_values().height().is_auto()
&& box.computed_values().width().is_auto()
&& !box.has_natural_width()
&& !box.has_natural_height()) {
return false;
}
return true;
}
return false;
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
}
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
bool FormattingContext::should_treat_max_width_as_none(Box const& box, AvailableSize const& available_width) const
LibWeb: Treat % max-width as none when containing block size indefinite This is technically "undefined behavior" per CSS 2.2, but it seems sensible to mirror the behavior of max-height in the same situation. It also appears to match how other engines behave. Fixes #19242
2023-06-14 18:35:02 +02:00
{
auto const& max_width = box.computed_values().max_width();
if (max_width.is_none())
return true;
LibWeb: Fix infinite recursion when grid has "max-width: max-content" With this change "max-width: max-content" is treated as "none" when the available width is also "max-content". This fix prevents a stack overflow in the grid track size maximization algorithm by avoiding recursive calls to calculate_max_width() when determining the maximum grid container size.
2024-02-20 21:50:48 +01:00
if (available_width.is_max_content() && max_width.is_max_content())
return true;
LibWeb: Treat % max-width as none when containing block size indefinite This is technically "undefined behavior" per CSS 2.2, but it seems sensible to mirror the behavior of max-height in the same situation. It also appears to match how other engines behave. Fixes #19242
2023-06-14 18:35:02 +02:00
if (box.is_absolutely_positioned())
return false;
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (max_width.contains_percentage()) {
LibWeb: Ignore % max-width if box is sized under max-content constraint When a box is sized under max-content constraint, any percentage value set for max-width should be considered as if it were infinite. In other words, it should have no effect on restricting the box's width.
2023-08-18 02:06:22 +02:00
if (available_width.is_max_content())
return true;
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (available_width.is_min_content())
return false;
if (!m_state.get(*box.non_anonymous_containing_block()).has_definite_width())
return true;
}
LibWeb: Set max-width for inline child boxes after inside layout max-width for boxes with inline children can only be applied after inside layout is done and width of box content is known. Fixes https://github.com/SerenityOS/serenity/issues/20235
2023-08-02 01:02:44 +03:00
if (box.children_are_inline()) {
if (max_width.is_fit_content() && available_width.is_intrinsic_sizing_constraint())
return true;
if (max_width.is_max_content() && available_width.is_max_content())
return true;
if (max_width.is_min_content() && available_width.is_min_content())
return true;
}
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
LibWeb: Treat % max-width as none when containing block size indefinite This is technically "undefined behavior" per CSS 2.2, but it seems sensible to mirror the behavior of max-height in the same situation. It also appears to match how other engines behave. Fixes #19242
2023-06-14 18:35:02 +02:00
return false;
}
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
bool FormattingContext::should_treat_max_height_as_none(Box const& box, AvailableSize const& available_height) const
LibWeb: Treat % max-height as none when containing block size indefinite Fixes #19371
2023-06-14 15:33:06 +02:00
{
// https://www.w3.org/TR/CSS22/visudet.html#min-max-heights
// If the height of the containing block is not specified explicitly (i.e., it depends on content height),
// and this element is not absolutely positioned, the percentage value is treated as '0' (for 'min-height')
// or 'none' (for 'max-height').
auto const& max_height = box.computed_values().max_height();
if (max_height.is_none())
return true;
if (box.is_absolutely_positioned())
return false;
LibWeb: Resolve % min-sizes against 0 while under min-content constraint When resolving a percentage min-width or min-height size against a containing block currently under a min-content constraint, we should act as if the containing block has zero size in that axis.
2023-06-16 13:46:55 +02:00
if (max_height.contains_percentage()) {
if (available_height.is_min_content())
return false;
if (!m_state.get(*box.non_anonymous_containing_block()).has_definite_height())
return true;
}
LibWeb: Treat % max-height as none when containing block size indefinite Fixes #19371
2023-06-14 15:33:06 +02:00
return false;
}
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