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

1389 lines
66 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: 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
#include <LibWeb/Layout/InitialContainingBlock.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: Remove hand-rolled is_foo() helpers in Layout::Node classes
2021-01-01 18:55:47 +01:00
#include <LibWeb/Layout/TableBox.h>
#include <LibWeb/Layout/TableCellBox.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>
namespace Web::Layout {
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
FormattingContext::FormattingContext(Type type, 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)
, 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: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
OwnPtr<FormattingContext> FormattingContext::create_independent_formatting_context_if_needed(LayoutState& state, Box const& child_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: 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
if (child_box.is_replaced_box() && !child_box.can_have_children()) {
// NOTE: This is a bit strange.
// Basically, we create a pretend formatting context for replaced elements that does nothing.
// This allows other formatting contexts to treat them like elements that actually need inside layout
// without having separate code to handle replaced elements.
// FIXME: Find a better abstraction for this.
struct ReplacedFormattingContext : public FormattingContext {
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
ReplacedFormattingContext(LayoutState& state, Box const& box)
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
: FormattingContext(Type::Block, state, box)
{
}
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
virtual CSSPixels automatic_content_height() const override { return 0; };
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
virtual void run(Box const&, LayoutMode, AvailableSpace const&) override { }
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
};
return make<ReplacedFormattingContext>(state, child_box);
}
LibWeb: Don't attempt to layout the inside of childless boxes Some boxes cannot have children (most commonly replaced elements), and so there is nothing meaningful inside them to layout. We now use the can_have_children() flag to quickly skip over such boxes instead of creating a formatting context and other pointless busywork.
2021-10-06 21:42:42 +02:00
if (!child_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: Use Layout::Node::display() everywhere
2022-10-06 16:02:53 +02:00
auto child_display = child_box.display();
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: 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 (is<SVGSVGBox>(child_box))
LibWeb: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
return make<SVGFormattingContext>(state, child_box, this);
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: 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_display.is_flex_inside())
LibWeb: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
return make<FlexFormattingContext>(state, child_box, this);
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: 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 (creates_block_formatting_context(child_box))
LibWeb: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
return make<BlockFormattingContext>(state, verify_cast<BlockContainer>(child_box), this);
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: 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_display.is_table_inside())
LibWeb: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
return make<TableFormattingContext>(state, verify_cast<TableBox>(child_box), this);
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: Add GridFormattingContext
2022-08-23 10:36:27 +02:00
if (child_display.is_grid_inside()) {
LibWeb: Make grid containers be Layout::Box Grid containers were incorrectly represented as BlockContainer before. Furthermore, GridFormattingContext had a bogus inheritance relationship with BlockFormattingContext. This patch brings our architecture closer to spec by making grid containers be plain boxes and making GFC not inherit from BFC.
2023-01-23 15:19:32 +01:00
return make<GridFormattingContext>(state, child_box, this);
LibWeb: Add GridFormattingContext
2022-08-23 10:36:27 +02: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
VERIFY(is_block_formatting_context());
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
if (child_box.children_are_inline())
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: 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
// The child box is a block container that doesn't create its own BFC.
// It will be formatted by this BFC.
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
if (!child_display.is_flow_inside()) {
Everywhere: Rename to_{string => deprecated_string}() where applicable This will make it easier to support both string types at the same time while we convert code, and tracking down remaining uses. One big exception is Value::to_string() in LibJS, where the name is dictated by the ToString AO.
2022-12-06 01:12:49 +00:00
dbgln("FIXME: Child box doesn't create BFC, but inside is also not flow! display={}", child_display.to_deprecated_string());
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.
struct DummyFormattingContext : public FormattingContext {
LibWeb: Rename FormattingState to LayoutState This seems a bit more descriptive (and also a bit shorter).
2022-07-16 23:30:32 +02:00
DummyFormattingContext(LayoutState& state, Box const& box)
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
: FormattingContext(Type::Block, state, box)
{
}
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
virtual CSSPixels automatic_content_height() const override { return 0; };
LibWeb: Reorganize layout algorithms around available space This is a big and messy change, and here's the gist: - AvaliableSpace is now 2x AvailableSize (width and height) - Layout algorithms are redesigned around the idea of available space - When doing layout across nested formatting contexts, the parent context tells the child context how much space is available for the child's root box in both axes. - "Available space" replaces "containing block width" in most places. - The width and height in a box's UsedValues are considered to be definite after they're assigned to. Marking something as having definite size is no longer a separate step, This probably introduces various regressions, but the big win here is that our layout system now works with available space, just like the specs are written. Fixing issues will be much easier going forward, since you don't need to do nearly as much conversion from "spec logic" to "LibWeb logic" as you previously did.
2022-09-27 15:29:17 +02:00
virtual void run(Box const&, LayoutMode, AvailableSpace const&) override { }
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: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
return make<DummyFormattingContext>(state, child_box);
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
VERIFY(child_box.is_block_container());
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
VERIFY(child_display.is_flow_inside());
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: 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: Pass state to create_independent_formatting_context_if_needed() Instead of using the current m_state implicitly, make this function take a FormattingState&. This will allow us to use it for throwaway layouts.
2022-02-27 10:10:45 +01:00
auto independent_formatting_context = create_independent_formatting_context_if_needed(m_state, 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: 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
independent_formatting_context->run(child_box, layout_mode, 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: 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
run(child_box, layout_mode, 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: 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::greatest_child_width(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: 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: 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: 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
static CSSPixelSize solve_replaced_size_constraint(LayoutState const& state, CSSPixels w, CSSPixels h, ReplacedBox const& box)
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: 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: 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& containing_block = *box.containing_block();
auto const& containing_block_state = state.get(containing_block);
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
auto width_of_containing_block = CSS::Length::make_px(containing_block_state.content_width());
auto height_of_containing_block = CSS::Length::make_px(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: 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 specified_min_width = box.computed_values().min_width().is_auto() ? 0 : box.computed_values().min_width().resolved(box, width_of_containing_block).to_px(box);
CSSPixels specified_max_width = box.computed_values().max_width().is_none() ? w : box.computed_values().max_width().resolved(box, width_of_containing_block).to_px(box);
CSSPixels specified_min_height = box.computed_values().min_height().is_auto() ? 0 : box.computed_values().min_height().resolved(box, height_of_containing_block).to_px(box);
CSSPixels specified_max_height = box.computed_values().max_height().is_none() ? h : box.computed_values().max_height().resolved(box, height_of_containing_block).to_px(box);
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
auto min_width = min(specified_min_width, specified_max_width);
auto max_width = max(specified_min_width, specified_max_width);
auto min_height = min(specified_min_height, specified_max_height);
auto max_height = max(specified_min_height, specified_max_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: 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
if (w > max_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
return { w, max(max_width * (h / w), min_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
if (w < min_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
return { max_width, min(min_width * (h / w), max_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
if (h > max_height)
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(max_height * (w / h), min_width), max_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
if (h < min_height)
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 { min(min_height * (w / h), max_width), min_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
if ((w > max_width && h > max_height) && (max_width / w < max_height / h))
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_width, max(min_height, max_width * (h / w)) };
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
if ((w > max_width && h > max_height) && (max_width / w > max_height / h))
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(min_width, max_height * (w / h)), max_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
if ((w < min_width && h < min_height) && (min_width / w < min_height / h))
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 { min(max_width, min_height * (w / h)), min_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
if ((w < min_width && h < min_height) && (min_width / w > min_height / h))
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 { min_width, min(max_height, min_width * (h / w)) };
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
if (w < min_width && h > max_height)
return { min_width, max_height };
if (w > max_width && h < min_height)
return { max_width, min_height };
return { w, 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
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.
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
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: 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 margin_box = margin_box_rect_in_ancestor_coordinate_space(*floating_box, root, m_state);
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 floating_box_bottom_margin_edge = margin_box.bottom() + 1;
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: 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: 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::tentative_width_for_replaced_element(LayoutState const& state, ReplacedBox const& box, CSS::Size const& computed_width, AvailableSpace const& 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: 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).
if (computed_width.is_percentage() && !state.get(*box.containing_block()).has_definite_width())
return 0;
auto height_of_containing_block = CSS::Length::make_px(containing_block_height_for(box, state));
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: 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 used_width = computed_width.resolved(box, CSS::Length::make_px(available_space.width.to_px())).to_px(box);
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: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
if (computed_height.is_auto() && computed_width.is_auto() && box.has_intrinsic_width())
return box.intrinsic_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: Cleanup + spec comments in replaced element width computation
2021-10-14 23:07:53 +02:00
if ((computed_height.is_auto() && computed_width.is_auto() && !box.has_intrinsic_width() && box.has_intrinsic_height() && box.has_intrinsic_aspect_ratio())
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
|| (computed_width.is_auto() && !computed_height.is_auto() && box.has_intrinsic_aspect_ratio())) {
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
return compute_height_for_replaced_element(state, box, available_space) * box.intrinsic_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: 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'.
if (computed_width.is_auto() && box.has_intrinsic_width())
return box.intrinsic_width().value();
// 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
{
if (is<ReplacedBox>(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
compute_width_for_absolutely_positioned_replaced_element(verify_cast<ReplacedBox>(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
{
if (is<ReplacedBox>(box))
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_replaced_element(static_cast<ReplacedBox const&>(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: 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::compute_width_for_replaced_element(LayoutState const& state, ReplacedBox const& box, AvailableSpace const& available_space)
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: 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 width_of_containing_block_as_length = CSS::Length::make_px(available_space.width.to_px());
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: 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
auto margin_left = box.computed_values().margin().left().resolved(box, width_of_containing_block_as_length).resolved(box);
auto margin_right = box.computed_values().margin().right().resolved(box, width_of_containing_block_as_length).resolved(box);
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
// A computed value of 'auto' for 'margin-left' or 'margin-right' becomes a used value of '0'.
if (margin_left.is_auto())
margin_left = zero_value;
if (margin_right.is_auto())
margin_right = zero_value;
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: 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: 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 used_width = tentative_width_for_replaced_element(state, 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
// 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: 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_max_width = box.computed_values().max_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_max_width.is_none()) {
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
if (used_width > computed_max_width.resolved(box, width_of_containing_block_as_length).to_px(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
used_width = tentative_width_for_replaced_element(state, 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()) {
if (used_width < computed_min_width.resolved(box, width_of_containing_block_as_length).to_px(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
used_width = tentative_width_for_replaced_element(state, 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: 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::tentative_height_for_replaced_element(LayoutState const& state, ReplacedBox const& box, CSS::Size const& computed_height, AvailableSpace const& 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: 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: 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
if (should_treat_width_as_auto(box, available_space) && should_treat_height_as_auto(box, available_space) && box.has_intrinsic_height())
LibWeb: Cleanup + spec comments in replaced element height computation
2021-10-14 23:15:36 +02:00
return box.intrinsic_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)
if (computed_height.is_auto() && box.has_intrinsic_aspect_ratio())
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
return compute_width_for_replaced_element(state, box, available_space) / box.intrinsic_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'.
if (computed_height.is_auto() && box.has_intrinsic_height())
return box.intrinsic_height().value();
// 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: 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
return computed_height.resolved(box, CSS::Length::make_px(available_space.height.to_px())).to_px(box);
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: 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::compute_height_for_replaced_element(LayoutState const& state, ReplacedBox const& box, AvailableSpace const& 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
{
// 10.6.2 Inline replaced elements, block-level replaced elements in normal flow,
// 'inline-block' replaced elements in normal flow and floating replaced elements
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 width_of_containing_block_as_length = CSS::Length::make_px(available_space.width.to_px());
auto height_of_containing_block_as_length = CSS::Length::make_px(available_space.height.to_px());
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: 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 used_height = tentative_height_for_replaced_element(state, 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: 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
if (computed_width.is_auto() && computed_height.is_auto() && box.has_intrinsic_aspect_ratio()) {
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 w = tentative_width_for_replaced_element(state, box, computed_width, available_space);
CSSPixels h = used_height;
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
used_height = solve_replaced_size_constraint(state, w, h, box).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
}
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: 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 width_of_containing_block = available_space.width.to_px();
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 width_of_containing_block_as_length = CSS::Length::make_px(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& computed_values = box.computed_values();
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: 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
auto const padding_left = computed_values.padding().left().resolved(box, width_of_containing_block_as_length).to_px(box);
auto const padding_right = computed_values.padding().right().resolved(box, width_of_containing_block_as_length).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
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
auto try_compute_width = [&](auto const& a_width) {
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
margin_left = computed_values.margin().left().resolved(box, width_of_containing_block_as_length).resolved(box);
margin_right = computed_values.margin().right().resolved(box, width_of_containing_block_as_length).resolved(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: 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
auto left = computed_values.inset().left().resolved(box, width_of_containing_block_as_length).resolved(box);
auto right = computed_values.inset().right().resolved(box, width_of_containing_block_as_length).resolved(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
auto width = a_width;
auto solve_for_left = [&] {
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 CSS::Length::make_px(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.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
};
auto 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
return CSS::Length::make_px(width_of_containing_block - left.to_px(box) - margin_left.to_px(box) - border_left - padding_left - padding_right - border_right - margin_right.to_px(box) - 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
};
auto solve_for_right = [&] {
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 CSS::Length::make_px(width_of_containing_block - left.to_px(box) - 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':
if (left.is_auto() && width.is_auto() && right.is_auto()) {
// 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.
// FIXME: This is very hackish.
left = CSS::Length::make_px(0);
goto Rule3;
}
if (!left.is_auto() && !width.is_auto() && !right.is_auto()) {
// FIXME: This should be solved in a more complicated way.
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'
if (left.is_auto() && width.is_auto() && !right.is_auto()) {
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').
else if (left.is_auto() && right.is_auto() && !width.is_auto()) {
// FIXME: Check direction
// FIXME: Use the static-position containing block
left = zero_value;
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'
else if (width.is_auto() && right.is_auto() && !left.is_auto()) {
Rule3:
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'
else if (left.is_auto() && !width.is_auto() && !right.is_auto()) {
left = solve_for_left();
}
// 5. 'width' is 'auto', 'left' and 'right' are not 'auto', then solve for 'width'
else if (width.is_auto() && !left.is_auto() && !right.is_auto()) {
width = solve_for_width();
}
// 6. 'right' is 'auto', 'left' and 'width' are not 'auto', then solve for 'right'
else if (right.is_auto() && !left.is_auto() && !width.is_auto()) {
right = solve_for_right();
}
return width;
};
// 1. The tentative used width is calculated (without 'min-width' and 'max-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 used_width = try_compute_width(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: 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.max_width().is_none()) {
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: 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 (used_width.to_px(box) > max_width.to_px(box)) {
used_width = try_compute_width(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: 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 (used_width.to_px(box) < min_width.to_px(box)) {
used_width = try_compute_width(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: 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: 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.border_left = border_left;
box_state.border_right = border_right;
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: 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_replaced_element(ReplacedBox 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
// The used value of 'width' is determined as for inline replaced elements.
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
// FIXME: This const_cast is gross.
const_cast<ReplacedBox&>(box).prepare_for_replaced_layout();
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
m_state.get_mutable(box).set_content_width(compute_width_for_replaced_element(m_state, 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: 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: 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();
auto height = box.computed_values().height();
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);
auto width_of_containing_block_as_length = CSS::Length::make_px(width_of_containing_block);
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 height_of_containing_block = available_space.height.to_px();
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 height_of_containing_block_as_length = CSS::Length::make_px(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: 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
auto solve_for = [&](CSS::Length length) {
return CSS::Length::make_px(
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
height_of_containing_block
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
- top.resolved(box, height_of_containing_block_as_length).to_px(box)
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
- margin_top.resolved(box, width_of_containing_block_as_length).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
- box.computed_values().border_top().width
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
- box.computed_values().padding().top().resolved(box, width_of_containing_block_as_length).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
- height.resolved(box, height_of_containing_block_as_length).to_px(box)
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
- box.computed_values().padding().bottom().resolved(box, width_of_containing_block_as_length).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
- box.computed_values().border_bottom().width
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
- margin_bottom.resolved(box, width_of_containing_block_as_length).to_px(box)
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
- bottom.resolved(box, height_of_containing_block_as_length).to_px(box)
+ length.to_px(box));
};
auto solve_for_top = [&] {
top = solve_for(top.resolved(box, height_of_containing_block_as_length));
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 solve_for_bottom = [&] {
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
bottom = solve_for(bottom.resolved(box, height_of_containing_block_as_length));
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: 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 solve_for_height = [&] {
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
height = CSS::Size::make_length(solve_for(height.resolved(box, height_of_containing_block_as_length)));
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: 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
auto solve_for_margin_top = [&] {
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
margin_top = solve_for(margin_top.resolved(box, width_of_containing_block_as_length));
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: 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
auto solve_for_margin_bottom = [&] {
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
margin_bottom = solve_for(margin_bottom.resolved(box, width_of_containing_block_as_length));
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 solve_for_margin_top_and_margin_bottom = [&] {
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 remainder = solve_for(CSS::Length::make_px(margin_top.resolved(box, width_of_containing_block_as_length).to_px(box) + margin_bottom.resolved(box, width_of_containing_block_as_length).to_px(box))).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
margin_top = CSS::Length::make_px(remainder / 2);
margin_bottom = CSS::Length::make_px(remainder / 2);
};
// If all three of top, height, and bottom are auto:
if (top.is_auto() && height.is_auto() && bottom.is_auto()) {
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
// (If we haven't done inside layout yet, we can't compute the auto height.)
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return;
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
// 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);
// then set top to the static position,
auto static_position = calculate_static_position(box);
top = CSS::Length::make_px(static_position.y());
// and finally apply rule number three below.
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
height = CSS::Size::make_px(compute_auto_height_for_block_formatting_context_root(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
solve_for_bottom();
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
// 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();
}
// 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();
}
// If the values are over-constrained,
else {
// ignore the value for bottom and solve for that value.
solve_for_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: 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
// 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()) {
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
// (If we haven't done inside layout yet, we can't compute the auto height.)
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return;
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
// then the height is based on the Auto heights for block formatting context roots,
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
height = CSS::Size::make_px(compute_auto_height_for_block_formatting_context_root(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
// and solve for top.
solve_for_top();
}
// 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());
// then solve for bottom.
solve_for_bottom();
}
// 3. If height and bottom are auto and top is not auto,
else if (height.is_auto() && bottom.is_auto() && !top.is_auto()) {
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
// (If we haven't done inside layout yet, we can't compute the auto height.)
if (before_or_after_inside_layout == BeforeOrAfterInsideLayout::Before)
return;
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
// then the height is based on the Auto heights for block formatting context roots,
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
height = CSS::Size::make_px(compute_auto_height_for_block_formatting_context_root(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
// and solve for bottom.
solve_for_bottom();
}
// 4. If top is auto, height and bottom are not auto,
LibWeb: Add missing else's in absolutely positioned height computation Rules 1, 2, and 3 use else if, so rules 4, 5, and 6 should too.
2022-10-12 00:27:20 -04:00
else if (top.is_auto() && !height.is_auto() && !bottom.is_auto()) {
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
// then solve for top.
solve_for_top();
}
// 5. If height is auto, top and bottom are not auto,
LibWeb: Add missing else's in absolutely positioned height computation Rules 1, 2, and 3 use else if, so rules 4, 5, and 6 should too.
2022-10-12 00:27:20 -04:00
else if (height.is_auto() && !top.is_auto() && !bottom.is_auto()) {
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
// then solve for height.
solve_for_height();
}
// 6. If bottom is auto, top and height are not auto,
LibWeb: Add missing else's in absolutely positioned height computation Rules 1, 2, and 3 use else if, so rules 4, 5, and 6 should too.
2022-10-12 00:27:20 -04:00
else if (bottom.is_auto() && !top.is_auto() && !height.is_auto()) {
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
// then solve for bottom.
solve_for_bottom();
}
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: Constrain abspos element heights by min-height and max-height
2022-10-11 22:31:51 +02:00
auto used_height = height.resolved(box, height_of_containing_block_as_length).to_px(box);
auto const& computed_min_height = box.computed_values().min_height();
auto const& computed_max_height = box.computed_values().max_height();
if (!computed_max_height.is_none())
used_height = min(used_height, computed_max_height.resolved(box, height_of_containing_block_as_length).resolved(box).to_px(box));
if (!computed_min_height.is_auto())
used_height = max(used_height, computed_min_height.resolved(box, height_of_containing_block_as_length).resolved(box).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
// 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);
box_state.margin_top = margin_top.resolved(box, width_of_containing_block_as_length).to_px(box);
box_state.margin_bottom = margin_bottom.resolved(box, width_of_containing_block_as_length).to_px(box);
box_state.border_top = box.computed_values().border_top().width;
box_state.border_bottom = box.computed_values().border_bottom().width;
box_state.padding_top = box.computed_values().padding().top().resolved(box, width_of_containing_block_as_length).to_px(box);
box_state.padding_bottom = box.computed_values().padding().bottom().resolved(box, width_of_containing_block_as_length).to_px(box);
// And here is where we assign the box's content height.
LibWeb: Constrain abspos element heights by min-height and max-height
2022-10-11 22:31:51 +02:00
box_state.set_content_height(used_height);
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: 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
static CSSPixelRect content_box_rect_in_static_position_ancestor_coordinate_space(Box const& box, Box const& ancestor_box, LayoutState const& state)
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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto rect = content_box_rect(box, state);
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;
for (auto const* current = box.parent(); current; current = current->parent()) {
if (current == &ancestor_box)
return rect;
auto const& current_state = state.get(static_cast<Box const&>(*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: 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 x = 0.0f;
CSSPixels y = 0.0f;
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: Convert Paintable coordinates to new pixel units This fixes a few sizing issues too. The page size is now correct in most cases! \o/ We get to remove some of the `to_type<>()` shenanigans, though it reappears in some other places.
2022-10-31 19:46:55 +00:00
y = (last_fragment->offset().y() + last_fragment->height()).value();
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: Return content box position from calculate_static_position This change makes calculate_static_position to return content box for both x and y (at least for the case when children are not inline). It makes it possible to be consistent about x and y when calculating box offset inside layout_absolutely_positioned_element.
2022-11-19 05:11:38 +03:00
x = m_state.get(box).margin_box_left();
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: Introduce structure that maintains collapsible margins in BFC Previously y position of boxes in block formatting context was calculated by looking at y position of previous in-flow sibling and adding collapsed margin of "collapse through" boxes lying between box currently being laid out and it's previous in-flow sibling. Here introduced BlockMarginState structure that maintains array of currently collapsible margins hence we no longer need to look at previous sibling to calculate y position of a box.
2022-12-25 17:13:21 +03:00
y = m_state.get(box).margin_box_top();
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
}
auto offset_to_static_parent = content_box_rect_in_static_position_ancestor_coordinate_space(box, *box.containing_block(), m_state);
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: 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: 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 width_of_containing_block = available_space.width.to_px();
auto height_of_containing_block = available_space.height.to_px();
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 width_of_containing_block_as_length = CSS::Length::make_px(width_of_containing_block);
auto height_of_containing_block_as_length = CSS::Length::make_px(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: 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 specified_width = box.computed_values().width().resolved(box, width_of_containing_block_as_length).resolved(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: 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: 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: 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
box_state.margin_left = box.computed_values().margin().left().resolved(box, width_of_containing_block_as_length).to_px(box);
LibWeb: Vertical % margins are relative to containing block width We were messing this up on absolutely positioned elements by using the containing block height instead.
2022-10-01 00:46:04 +02:00
box_state.margin_top = box.computed_values().margin().top().resolved(box, width_of_containing_block_as_length).to_px(box);
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
box_state.margin_right = box.computed_values().margin().right().resolved(box, width_of_containing_block_as_length).to_px(box);
LibWeb: Vertical % margins are relative to containing block width We were messing this up on absolutely positioned elements by using the containing block height instead.
2022-10-01 00:46:04 +02:00
box_state.margin_bottom = box.computed_values().margin().bottom().resolved(box, width_of_containing_block_as_length).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
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.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: 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: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
auto const& computed_left = box.computed_values().inset().left();
auto const& computed_right = box.computed_values().inset().right();
auto const& computed_top = box.computed_values().inset().top();
auto const& computed_bottom = box.computed_values().inset().bottom();
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: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
box_state.inset_left = computed_left.resolved(box, width_of_containing_block_as_length).to_px(box);
box_state.inset_top = computed_top.resolved(box, height_of_containing_block_as_length).to_px(box);
box_state.inset_right = computed_right.resolved(box, width_of_containing_block_as_length).to_px(box);
box_state.inset_bottom = computed_bottom.resolved(box, height_of_containing_block_as_length).to_px(box);
if (computed_left.is_auto() && box.computed_values().width().is_auto() && computed_right.is_auto()) {
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
if (box.computed_values().margin().left().is_auto())
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 = 0;
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
if (box.computed_values().margin().right().is_auto())
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_right = 0;
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
auto static_position = calculate_static_position(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: 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 parent and sibling positions for absolutely positioned div If absolutely positioned divs do not have a fixed position, then their position must be calculated based off of the position of their parent and their siblings.
2022-08-10 19:21:29 +02:00
LibWeb: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
if (!computed_left.is_auto()) {
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 x_offset = box_state.inset_left
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.border_box_left();
used_offset.set_x(x_offset + box_state.margin_left);
LibWeb: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
} else if (!computed_right.is_auto()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels x_offset = CSSPixels(0)
LibWeb: Rename "offset" in box model metrics to "inset" The CSS Positioned Layout spec refers to the top/left/bottom/right properties as "inset" properties, so let's use the same terminology.
2022-03-26 13:26:42 +01:00
- box_state.inset_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.border_box_right();
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
used_offset.set_x(width_of_containing_block + x_offset - box_state.content_width() - box_state.margin_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
} else {
LibWeb: Return content box position from calculate_static_position This change makes calculate_static_position to return content box for both x and y (at least for the case when children are not inline). It makes it possible to be consistent about x and y when calculating box offset inside layout_absolutely_positioned_element.
2022-11-19 05:11:38 +03:00
// NOTE: static position is content box position so border_box and margin should not be added
used_offset.set_x(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
}
LibWeb: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
if (!computed_top.is_auto()) {
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 y_offset = box_state.inset_top
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.border_box_top();
used_offset.set_y(y_offset + box_state.margin_top);
LibWeb: Add helpful locals in layout_absolutely_positioned_element() This code had some obnoxiously repetetive call chains.
2022-10-01 12:33:30 +02:00
} else if (!computed_bottom.is_auto()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
CSSPixels y_offset = CSSPixels(0)
LibWeb: Rename "offset" in box model metrics to "inset" The CSS Positioned Layout spec refers to the top/left/bottom/right properties as "inset" properties, so let's use the same terminology.
2022-03-26 13:26:42 +01:00
- box_state.inset_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
- box_state.border_box_bottom();
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
used_offset.set_y(height_of_containing_block + y_offset - box_state.content_height() - box_state.margin_bottom);
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: Return content box position from calculate_static_position This change makes calculate_static_position to return content box for both x and y (at least for the case when children are not inline). It makes it possible to be consistent about x and y when calculating box offset inside layout_absolutely_positioned_element.
2022-11-19 05:11:38 +03:00
// NOTE: static position is content box position so border_box and margin should not be added
used_offset.set_y(static_position.y());
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 containing block padding when placing abspos boxes Unlike the other positioning schemes, absolute positioning is relative to the *padding* edge of the containing block.
2022-09-14 14:38:55 +02:00
// NOTE: Absolutely positioned boxes are relative to the *padding edge* of the containing block.
used_offset.translate_by(-containing_block_state.padding_left, -containing_block_state.padding_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: 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_replaced_element(ReplacedBox const& box, AvailableSpace const& available_space, BeforeOrAfterInsideLayout)
LibWeb: Move absolute positioning up to FormattingContext It seems like both BFC and IFC can have absolutely positioned children. It's a bit strange, but consider the following HTML: <html><body>foobar<img style="position: absolute"></body></html> In such a document, the <img> element is an absolutely positioned child of a block-level element (<body>) with no block-level children. An IFC is established for <body>, and needs to handle layout for <img>.
2021-01-06 18:18:46 +01:00
{
LibWeb: 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
// The used value of 'height' is determined as for inline replaced elements.
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
m_state.get_mutable(box).set_content_height(compute_height_for_replaced_element(m_state, box, available_space));
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: Rename FormattingContext::compute_position() => compute_inset() This function computes the used inset properties, not the position of a box per se, so let's call it something more accurate.
2022-03-27 15:35:28 +02:00
void FormattingContext::compute_inset(Box 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
{
if (box.computed_values().position() != CSS::Position::Relative)
return;
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
auto resolve_two_opposing_insets = [&](CSS::LengthPercentage const& computed_start, CSS::LengthPercentage const& computed_end, CSSPixels& used_start, CSSPixels& used_end, CSSPixels 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
auto resolved_first = computed_start.resolved(box, CSS::Length::make_px(reference_for_percentage)).resolved(box);
auto resolved_second = computed_end.resolved(box, CSS::Length::make_px(reference_for_percentage)).resolved(box);
if (resolved_first.is_auto() && resolved_second.is_auto()) {
// 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;
} else if (resolved_first.is_auto() || resolved_second.is_auto()) {
// If only one is auto, its used value becomes the negation of the other, and the box is shifted by the specified amount.
if (resolved_first.is_auto()) {
used_end = resolved_second.to_px(box);
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 {
used_start = resolved_first.to_px(box);
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.
used_start = resolved_first.to_px(box);
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()) {
return max(calculate_min_content_height(box, available_space.width),
min(calculate_stretch_fit_height(box, available_space.height),
calculate_max_content_height(box, available_space.width)));
}
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())
return calculate_min_content_height(box, available_space.width);
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.
return calculate_max_content_height(box, available_space.width);
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: 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 (box.has_intrinsic_width())
return *box.intrinsic_width();
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: 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 context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, box);
VERIFY(context);
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();
context->run(box, LayoutMode::IntrinsicSizing, AvailableSpace(available_width, available_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
if (context->type() == FormattingContext::Type::Flex) {
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
cache.min_content_width = box_state.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
} else {
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
cache.min_content_width = context->greatest_child_width(box).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: 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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
if (!isfinite(cache.min_content_width->value())) {
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: 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 (box.has_intrinsic_width())
return *box.intrinsic_width();
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: 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 context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, box);
VERIFY(context);
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();
context->run(box, LayoutMode::IntrinsicSizing, AvailableSpace(available_width, available_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
if (context->type() == FormattingContext::Type::Flex) {
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
cache.max_content_width = box_state.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
} else {
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
cache.max_content_width = context->greatest_child_width(box).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: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
if (!isfinite(cache.max_content_width->value())) {
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: 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_height(Layout::Box const& box, AvailableSize const& available_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: 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 (box.has_intrinsic_height())
return *box.intrinsic_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
bool is_cacheable = available_width.is_definite() || available_width.is_intrinsic_sizing_constraint();
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
Optional<CSSPixels>* cache_slot = nullptr;
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
if (is_cacheable) {
auto& root_state = m_state.m_root;
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
if (available_width.is_definite()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
cache_slot = &cache.min_content_height_with_definite_available_width.ensure(available_width.to_px());
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
} else if (available_width.is_min_content()) {
cache_slot = &cache.min_content_height_with_min_content_available_width;
} else if (available_width.is_max_content()) {
cache_slot = &cache.min_content_height_with_max_content_available_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: 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
if (cache_slot && cache_slot->has_value())
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: 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 context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, box);
VERIFY(context);
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: 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
context->run(box, LayoutMode::IntrinsicSizing, AvailableSpace(available_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: 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
if (!isfinite(min_content_height.value())) {
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: 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
if (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: 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_height(Layout::Box const& box, AvailableSize const& available_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: 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 (box.has_intrinsic_height())
return *box.intrinsic_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
bool is_cacheable = available_width.is_definite() || available_width.is_intrinsic_sizing_constraint();
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
Optional<CSSPixels>* cache_slot = nullptr;
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
if (is_cacheable) {
auto& root_state = m_state.m_root;
auto& cache = *root_state.intrinsic_sizes.ensure(&box, [] { return adopt_own(*new LayoutState::IntrinsicSizes); });
if (available_width.is_definite()) {
LibWeb: Convert LayoutState to new pixel units
2022-11-04 20:32:50 +00:00
cache_slot = &cache.max_content_height_with_definite_available_width.ensure(available_width.to_px());
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
} else if (available_width.is_min_content()) {
cache_slot = &cache.max_content_height_with_min_content_available_width;
} else if (available_width.is_max_content()) {
cache_slot = &cache.max_content_height_with_max_content_available_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: 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
if (cache_slot && cache_slot->has_value())
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: 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 context = const_cast<FormattingContext*>(this)->create_independent_formatting_context_if_needed(throwaway_state, box);
VERIFY(context);
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: 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
context->run(box, LayoutMode::IntrinsicSizing, AvailableSpace(available_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: 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
if (!isfinite(max_content_height.value())) {
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;
}
if (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: Support box-sizing in BFC Add support for box-sizing in block formatting context, support for Flex Formatting Context and Grid Formatting Context is missing
2022-11-21 22:17:24 +03:00
CSS::Length FormattingContext::calculate_inner_width(Layout::Box const& box, AvailableSize const& available_width, CSS::Size const& width) const
{
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
auto width_of_containing_block = available_width.to_px();
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 width_of_containing_block_as_length_for_resolve = CSS::Length::make_px(width_of_containing_block);
if (width.is_auto()) {
return width.resolved(box, width_of_containing_block_as_length_for_resolve).resolved(box);
}
if (!available_width.is_definite())
width_of_containing_block_as_length_for_resolve = CSS::Length::make_px(0);
auto& computed_values = box.computed_values();
if (computed_values.box_sizing() == CSS::BoxSizing::BorderBox) {
auto const padding_left = computed_values.padding().left().resolved(box, width_of_containing_block_as_length_for_resolve).resolved(box);
auto const padding_right = computed_values.padding().right().resolved(box, width_of_containing_block_as_length_for_resolve).resolved(box);
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
auto inner_width = width.resolved(box, width_of_containing_block_as_length_for_resolve).resolved(box).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
- computed_values.border_left().width
- padding_left.to_px(box)
- computed_values.border_right().width
- padding_right.to_px(box);
return CSS::Length::make_px(max(inner_width, 0));
}
return width.resolved(box, width_of_containing_block_as_length_for_resolve).resolved(box);
}
CSS::Length FormattingContext::calculate_inner_height(Layout::Box const& box, AvailableSize const& available_height, CSS::Size const& height) const
{
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
auto height_of_containing_block = available_height.to_px();
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 height_of_containing_block_as_length_for_resolve = CSS::Length::make_px(height_of_containing_block);
if (height.is_auto()) {
return height.resolved(box, height_of_containing_block_as_length_for_resolve).resolved(box);
}
if (!available_height.is_definite())
height_of_containing_block_as_length_for_resolve = CSS::Length::make_px(0);
auto& computed_values = box.computed_values();
if (computed_values.box_sizing() == CSS::BoxSizing::BorderBox) {
LibWeb: Fix typo in calculate_inner_height
2022-11-25 19:02:50 +03:00
auto const padding_top = computed_values.padding().top().resolved(box, height_of_containing_block_as_length_for_resolve).resolved(box);
auto const padding_bottom = computed_values.padding().bottom().resolved(box, height_of_containing_block_as_length_for_resolve).resolved(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: 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
auto inner_height = height.resolved(box, height_of_containing_block_as_length_for_resolve).resolved(box).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
- computed_values.border_top().width
- padding_top.to_px(box)
- computed_values.border_bottom().width
- padding_bottom.to_px(box);
return CSS::Length::make_px(max(inner_height, 0));
}
return height.resolved(box, height_of_containing_block_as_length_for_resolve).resolved(box);
}
LibWeb: Convert FormattingContext to new pixel units Just FormattingContext and AvailableSpace, and the minor adjustments to make everything else work.
2022-11-23 17:46:10 +00:00
CSSPixels FormattingContext::containing_block_width_for(Box const& box, LayoutState const& state)
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& containing_block_state = state.get(*box.containing_block());
auto& box_state = state.get(box);
switch (box_state.width_constraint) {
case SizeConstraint::MinContent:
return 0;
case SizeConstraint::MaxContent:
return INFINITY;
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: 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::containing_block_height_for(Box const& box, LayoutState const& state)
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& containing_block_state = state.get(*box.containing_block());
auto& box_state = state.get(box);
switch (box_state.height_constraint) {
case SizeConstraint::MinContent:
return 0;
case SizeConstraint::MaxContent:
return INFINITY;
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: 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: 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_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.
// Undefined if the available space is indefinite.
auto const& box_state = m_state.get(box);
return available_width.to_px()
- 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: 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_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.
auto const& box_state = m_state.get(box);
return available_height.to_px()
- 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)
{
return box.computed_values().width().is_auto()
|| (box.computed_values().width().contains_percentage() && !available_space.width.is_definite());
}
bool FormattingContext::should_treat_height_as_auto(Box const& box, AvailableSpace const& available_space)
{
return box.computed_values().height().is_auto()
|| (box.computed_values().height().contains_percentage() && !available_space.height.is_definite());
}
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) {
if (!is<TextNode>(node) || !static_cast<TextNode const&>(node).dom_node().data().is_whitespace()) {
contains_only_white_space = false;
return IterationDecision::Break;
}
return IterationDecision::Continue;
});
if (contains_only_white_space)
return true;
}
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