Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/LayoutBlock.cpp

776 lines
34 KiB
C++
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
LibGUI: Remove leading G from filenames
2020-02-06 20:33:02 +01:00
#include <LibGUI/Painter.h>
LibWeb: Rename directory LibHTML => LibWeb Let's rename this to LibWeb since it aims to provide more parts of the web platform than just HTML. :^)
2020-03-07 10:32:51 +01:00
#include <LibWeb/CSS/StyleResolver.h>
#include <LibWeb/DOM/Element.h>
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
#include <LibWeb/Dump.h>
LibWeb: Rename directory LibHTML => LibWeb Let's rename this to LibWeb since it aims to provide more parts of the web platform than just HTML. :^)
2020-03-07 10:32:51 +01:00
#include <LibWeb/Layout/LayoutBlock.h>
LibWeb: Add basic support for position:fixed Fixed position elements have the ICB as their containing block. The magic of fixed positioning is implemented at the rendering stage, where we temporarily translate painting by the current scroll offset. Note that "absolutely positioned" includes both position:absolute and position:fixed.
2020-06-12 14:19:03 +02:00
#include <LibWeb/Layout/LayoutDocument.h>
LibWeb: Rename directory LibHTML => LibWeb Let's rename this to LibWeb since it aims to provide more parts of the web platform than just HTML. :^)
2020-03-07 10:32:51 +01:00
#include <LibWeb/Layout/LayoutInline.h>
#include <LibWeb/Layout/LayoutReplaced.h>
#include <LibWeb/Layout/LayoutText.h>
LibWeb: Start implementing proper layout of replaced elements LayoutReplaced now has intrinsic width, height and ratio. Only some of the values may be present. The layout algorithm takes the various configurations into account per the CSS specification. This is still pretty immature but at least we're moving forward. :^)
2020-06-05 19:13:27 +02:00
#include <LibWeb/Layout/LayoutWidget.h>
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
#include <math.h>
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
namespace Web {
LibHTML: Rename "style_properties" to "style" everywhere
2019-10-07 09:23:53 +02:00
LayoutBlock::LayoutBlock(const Node* node, NonnullRefPtr<StyleProperties> style)
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
: LayoutBox(node, move(style))
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
{
}
LayoutBlock::~LayoutBlock()
{
}
LibHTML: Add layout() overrides for LayoutText and LayoutBlock.
2019-06-20 23:00:26 +02:00
LibHTML: Create anonymous blocks around inline children of blocks.
2019-07-08 17:42:23 +02:00
LayoutNode& LayoutBlock::inline_wrapper()
{
LibHTML: Fix moving inline elements to unrelated block elements LayoutBlock::inline_wrapper() is supposed to return an inline wrapper, a special anonymous block element intended to wrap inline children of a block element that also has block children. Add a check for whether the existing block child element is anonymous (refers to a DOM node), and if it's not create a new anonymous wrapper.
2019-09-25 11:56:16 +03:00
if (!last_child() || !last_child()->is_block() || last_child()->node() != nullptr) {
LibHTML: Anonymous blocks *should* inherit some properties Okay, I got that a bit wrong. Here's what CSS 2.1 says: "The properties of anonymous boxes are inherited from the enclosing non-anonymous box. Non-inherited properties have their initial value." This patch implements a better behavior by only copying the inherited properties from the parent style.
2019-10-05 23:47:06 +02:00
append_child(adopt(*new LayoutBlock(nullptr, style_for_anonymous_block())));
LibHTML: Make "children are inline" flag imperative Instead of computing whether a block's children are inline based on the first child, make it an imperatively-set flag. This gives us some flexibility to ignore things like text nodes inside a <table>, for example. I'm still unsure what the "correct" way to deal with those will be. We'll find out sooner or later. :^)
2019-10-17 23:32:08 +02:00
last_child()->set_children_are_inline(true);
LibHTML: Create anonymous blocks around inline children of blocks.
2019-07-08 17:42:23 +02:00
}
return *last_child();
}
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
void LayoutBlock::layout(LayoutMode layout_mode)
LibHTML: Add layout() overrides for LayoutText and LayoutBlock.
2019-06-20 23:00:26 +02:00
{
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
compute_width();
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
layout_inside(layout_mode);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
compute_height();
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
layout_absolutely_positioned_descendants();
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
void LayoutBlock::layout_absolutely_positioned_descendant(LayoutBox& box)
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
{
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
box.layout(LayoutMode::Default);
auto& box_model = box.box_model();
auto& style = box.style();
auto zero_value = Length(0, Length::Type::Px);
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
auto specified_width = style.length_or_fallback(CSS::PropertyID::Width, Length(), width());
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
box_model.margin().top = style.length_or_fallback(CSS::PropertyID::MarginTop, {}, height());
box_model.margin().right = style.length_or_fallback(CSS::PropertyID::MarginRight, {}, width());
box_model.margin().bottom = style.length_or_fallback(CSS::PropertyID::MarginBottom, {}, height());
box_model.margin().left = style.length_or_fallback(CSS::PropertyID::MarginLeft, {}, width());
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
box_model.offset().top = style.length_or_fallback(CSS::PropertyID::Top, {}, height());
box_model.offset().right = style.length_or_fallback(CSS::PropertyID::Right, {}, width());
box_model.offset().bottom = style.length_or_fallback(CSS::PropertyID::Bottom, {}, height());
box_model.offset().left = style.length_or_fallback(CSS::PropertyID::Left, {}, width());
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
if (box_model.offset().left.is_auto() && specified_width.is_auto() && box_model.offset().right.is_auto()) {
if (box_model.margin().left.is_auto())
box_model.margin().left = zero_value;
if (box_model.margin().right.is_auto())
box_model.margin().right = zero_value;
}
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
Gfx::FloatPoint used_offset;
float x_offset = box_model.offset().left.to_px(box)
+ box_model.border_box(box).left
- box_model.offset().right.to_px(box)
- box_model.border_box(box).right;
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float y_offset = box_model.offset().top.to_px(box)
+ box_model.border_box(box).top
- box_model.offset().bottom.to_px(box)
- box_model.border_box(box).bottom;
LibWeb: Handle position:absolute with both left and right specified In this case, we need to undo the right-side offsetting, since the width computation algorithm will already have stretched the width to accomodate both the side constraints.
2020-06-23 20:05:35 +02:00
bool has_left_side_constraints = !box_model.offset().left.is_auto() || !box_model.margin().left.is_auto();
bool has_right_side_constraints = !box_model.offset().right.is_auto() || !box_model.margin().right.is_auto();
if (has_left_side_constraints && has_right_side_constraints) {
// If both 'left' and 'right' are set, we will have stretched the width to accomodate both.
x_offset += box_model.offset().right.to_px(box);
}
if (has_left_side_constraints) {
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
used_offset.set_x(x_offset + box_model.margin().left.to_px(box));
LibWeb: Handle position:absolute with both left and right specified In this case, we need to undo the right-side offsetting, since the width computation algorithm will already have stretched the width to accomodate both the side constraints.
2020-06-23 20:05:35 +02:00
} else if (has_right_side_constraints) {
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
used_offset.set_x(width() + x_offset - box.width() - box_model.margin().right.to_px(box));
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
if (!box_model.offset().top.is_auto()) {
used_offset.set_y(y_offset + box_model.margin().top.to_px(box));
} else if (!box_model.offset().bottom.is_auto()) {
used_offset.set_y(height() + y_offset - box.height() - box_model.margin().bottom.to_px(box));
}
box.set_offset(used_offset);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
void LayoutBlock::layout_inside(LayoutMode layout_mode)
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
{
if (children_are_inline())
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
layout_inline_children(layout_mode);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
else
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
layout_contained_boxes(layout_mode);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
void LayoutBlock::layout_absolutely_positioned_descendants()
{
for_each_in_subtree_of_type<LayoutBox>([&](auto& box) {
if (box.is_absolutely_positioned() && box.containing_block() == this) {
layout_absolutely_positioned_descendant(box);
}
return IterationDecision::Continue;
});
}
void LayoutBlock::layout_contained_boxes(LayoutMode layout_mode)
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
{
LibHTML: Use floating point numbers throughout the layout tree
2019-11-18 16:25:38 +01:00
float content_height = 0;
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float content_width = 0;
for_each_in_subtree_of_type<LayoutBox>([&](auto& box) {
if (box.is_absolutely_positioned() || box.containing_block() != this)
return IterationDecision::Continue;
box.layout(layout_mode);
if (box.is_replaced())
place_block_level_replaced_element_in_normal_flow(to<LayoutReplaced>(box));
else if (box.is_block())
place_block_level_non_replaced_element_in_normal_flow(to<LayoutBlock>(box));
LibWeb: Don't assert when containing block doesn't know how to place We can just log that we don't know what to do for now.
2020-06-14 22:07:00 +02:00
else
dbg() << "FIXME: LayoutBlock::layout_contained_boxes doesn't know how to place a " << box.class_name();
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
content_height = max(content_height, box.effective_offset().y() + box.height() + box.box_model().margin_box(*this).bottom);
content_width = max(content_width, to<LayoutBox>(box).width());
return IterationDecision::Continue;
LibHTML: Implement basic block height computation ..and add vertical box properties to the layout tree dumps.
2019-08-18 08:37:53 +02:00
});
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
LibWeb: Respect specified width when computing shrink-to-fit candidates Previously we would always just use the combined content width as the shrunken width in shrink-to-fit width calculations, but if the element has a non-auto specified width, we should just let that take over. This is far from perfect and doesn't take stuff like min/max-width into account. Will need more work, this just covers the basic case.
2020-06-23 18:55:25 +02:00
if (layout_mode != LayoutMode::Default) {
auto specified_width = style().length_or_fallback(CSS::PropertyID::Width, Length(), containing_block()->width());
if (specified_width.is_auto())
set_width(content_width);
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
set_height(content_height);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
LibHTML: Add layout() overrides for LayoutText and LayoutBlock.
2019-06-20 23:00:26 +02:00
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
void LayoutBlock::layout_inline_children(LayoutMode layout_mode)
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
{
ASSERT(children_are_inline());
m_line_boxes.clear();
for_each_child([&](auto& child) {
ASSERT(child.is_inline());
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
if (child.is_absolutely_positioned())
LibWeb: Remove absolutely positioned elements from the normal flow Skip over absolutely positioned children when laying out the inline children of a block. This takes them out of the flow and allows them to be positioned correctly relative to the (absolute) containing block.
2020-06-12 15:25:37 +02:00
return;
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
child.split_into_lines(*this, layout_mode);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
});
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
for (auto& line_box : m_line_boxes) {
line_box.trim_trailing_whitespace();
}
LibWeb: Implement <center> as -libweb-center To get the expected behavior for <center>, we needed a special text alignment mode that centers block-level elements (and not just line box fragments.)
2020-06-13 10:54:58 +02:00
auto text_align = style().text_align();
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
float min_line_height = style().line_height(*this);
LibHTML: Divide the "line spacing" evenly between lines of text Before this patch, all of the excess spacing caused by line-height was "padding" the line boxes below the text. To fix this, we make line box fragments use the font height as their height, and then let the inline layout algorithm adjust the Y positions to distribute the vertical space.
2019-11-25 18:12:12 +01:00
float line_spacing = min_line_height - style().font().glyph_height();
LibHTML: Use floating point numbers throughout the layout tree
2019-11-18 16:25:38 +01:00
float content_height = 0;
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
float max_linebox_width = 0;
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
for (auto& line_box : m_line_boxes) {
LibHTML: Use floating point numbers throughout the layout tree
2019-11-18 16:25:38 +01:00
float max_height = min_line_height;
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
for (auto& fragment : line_box.fragments()) {
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
max_height = max(max_height, fragment.height());
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
LibHTML: Implement CSS text-align: left/center/right This was easier than I imagined; we just shift each line box to the left based on the alignment and the remaining space on each line. :^)
2019-10-16 20:32:17 +02:00
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
float x_offset = 0;
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
float excess_horizontal_space = (float)width() - line_box.width();
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
LibHTML: Implement CSS text-align: left/center/right This was easier than I imagined; we just shift each line box to the left based on the alignment and the remaining space on each line. :^)
2019-10-16 20:32:17 +02:00
switch (text_align) {
case CSS::ValueID::Center:
LibWeb: Implement <center> as -libweb-center To get the expected behavior for <center>, we needed a special text alignment mode that centers block-level elements (and not just line box fragments.)
2020-06-13 10:54:58 +02:00
case CSS::ValueID::VendorSpecificCenter:
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
x_offset += excess_horizontal_space / 2;
LibHTML: Implement CSS text-align: left/center/right This was easier than I imagined; we just shift each line box to the left based on the alignment and the remaining space on each line. :^)
2019-10-16 20:32:17 +02:00
break;
case CSS::ValueID::Right:
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
x_offset += excess_horizontal_space;
LibHTML: Implement CSS text-align: left/center/right This was easier than I imagined; we just shift each line box to the left based on the alignment and the remaining space on each line. :^)
2019-10-16 20:32:17 +02:00
break;
case CSS::ValueID::Left:
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
case CSS::ValueID::Justify:
LibHTML: Implement CSS text-align: left/center/right This was easier than I imagined; we just shift each line box to the left based on the alignment and the remaining space on each line. :^)
2019-10-16 20:32:17 +02:00
default:
break;
}
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
float excess_horizontal_space_including_whitespace = excess_horizontal_space;
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
int whitespace_count = 0;
if (text_align == CSS::ValueID::Justify) {
for (auto& fragment : line_box.fragments()) {
if (fragment.is_justifiable_whitespace()) {
++whitespace_count;
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
excess_horizontal_space_including_whitespace += fragment.width();
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
}
}
}
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
float justified_space_width = whitespace_count ? (excess_horizontal_space_including_whitespace / (float)whitespace_count) : 0;
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
AK: Make Vector use size_t for its size and capacity
2020-02-25 14:49:47 +01:00
for (size_t i = 0; i < line_box.fragments().size(); ++i) {
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
auto& fragment = line_box.fragments()[i];
LibWeb: Start implementing proper layout of replaced elements LayoutReplaced now has intrinsic width, height and ratio. Only some of the values may be present. The layout algorithm takes the various configurations into account per the CSS specification. This is still pretty immature but at least we're moving forward. :^)
2020-06-05 19:13:27 +02:00
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
// Vertically align everyone's bottom to the line.
// FIXME: Support other kinds of vertical alignment.
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
fragment.set_offset({ roundf(x_offset + fragment.offset().x()), content_height + (max_height - fragment.height()) - (line_spacing / 2) });
LibHTML: Implement basic layout for inline <img alt> LayoutReplaced objects can now participate in inline layout. It's very hackish, but basically LayoutReplaced will just add itself to the last line in the containing block. This patch gets rid of the idea that only LayoutInline subclasses can be split into lines, by moving the split_into_lines() virtual up to LayoutNode and overriding it in LayoutReplaced.
2019-10-05 23:20:35 +02:00
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
if (text_align == CSS::ValueID::Justify) {
if (fragment.is_justifiable_whitespace()) {
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
if (fragment.width() != justified_space_width) {
float diff = justified_space_width - fragment.width();
fragment.set_width(justified_space_width);
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
// Shift subsequent sibling fragments to the right to adjust for change in width.
AK: Make Vector use size_t for its size and capacity
2020-02-25 14:49:47 +01:00
for (size_t j = i + 1; j < line_box.fragments().size(); ++j) {
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
auto offset = line_box.fragments()[j].offset();
offset.move_by(diff, 0);
line_box.fragments()[j].set_offset(offset);
LibHTML: Implement "text-align: justify" In order for this to work nicely, I made the line box classes use float instead of int for its geometry information. Justification works by distributing all of the whitespace on the line (including the trailing whitespace before the line break) evenly across the spaces in-between words. We should probably use floating point (or maybe fixed point?) for all the layout metrics stuff. But one thing at a time. :^)
2019-10-20 12:30:25 +02:00
}
}
}
}
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
if (fragment.layout_node().is_inline_block()) {
auto& inline_block = const_cast<LayoutBlock&>(to<LayoutBlock>(fragment.layout_node()));
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
inline_block.set_size(fragment.size());
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
inline_block.layout(layout_mode);
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
}
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
float final_line_box_width = 0;
for (auto& fragment : line_box.fragments())
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
final_line_box_width += fragment.width();
LibHTML: Remove trailing whitespace in line boxes After the splitting-into-lines pass, remove any trailing whitespace from all of a block's line boxes. This improves the appearance of text-align: justify/right :^)
2019-10-20 17:18:28 +02:00
line_box.m_width = final_line_box_width;
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
max_linebox_width = max(max_linebox_width, final_line_box_width);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
content_height += max_height;
}
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
if (layout_mode != LayoutMode::Default) {
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
set_width(max_linebox_width);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
}
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
set_height(content_height);
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
void LayoutBlock::compute_width_for_absolutely_positioned_block()
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
{
LibHTML: Rename "style_properties" to "style" everywhere
2019-10-07 09:23:53 +02:00
auto& style = this->style();
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
auto& containing_block = *this->containing_block();
auto zero_value = Length(0, Length::Type::Px);
LibWeb: Make sure BoxModelMetrics are set for position:absolute boxes This is all very redundant and we should find a way to share this code between at least some of the positioning modes.
2020-06-23 19:20:31 +02:00
Length margin_left;
Length margin_right;
Length border_left;
Length border_right;
Length padding_left;
Length padding_right;
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
auto try_compute_width = [&](const auto& a_width) {
LibWeb: Make sure BoxModelMetrics are set for position:absolute boxes This is all very redundant and we should find a way to share this code between at least some of the positioning modes.
2020-06-23 19:20:31 +02:00
margin_left = style.length_or_fallback(CSS::PropertyID::MarginLeft, zero_value, containing_block.width());
margin_right = style.length_or_fallback(CSS::PropertyID::MarginRight, zero_value, containing_block.width());
border_left = style.length_or_fallback(CSS::PropertyID::BorderLeftWidth, zero_value);
border_right = style.length_or_fallback(CSS::PropertyID::BorderRightWidth, zero_value);
padding_left = style.length_or_fallback(CSS::PropertyID::PaddingLeft, zero_value, containing_block.width());
padding_right = style.length_or_fallback(CSS::PropertyID::PaddingRight, zero_value, containing_block.width());
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
auto left = style.length_or_fallback(CSS::PropertyID::Left, {}, containing_block.width());
auto right = style.length_or_fallback(CSS::PropertyID::Right, {}, containing_block.width());
auto width = a_width;
auto solve_for_left = [&] {
return Length(containing_block.width() - margin_left.to_px(*this) - border_left.to_px(*this) - padding_left.to_px(*this) - width.to_px(*this) - padding_right.to_px(*this) - border_right.to_px(*this) - margin_right.to_px(*this) - right.to_px(*this), Length::Type::Px);
};
auto solve_for_width = [&] {
return Length(containing_block.width() - left.to_px(*this) - margin_left.to_px(*this) - border_left.to_px(*this) - padding_left.to_px(*this) - padding_right.to_px(*this) - border_right.to_px(*this) - margin_right.to_px(*this) - right.to_px(*this), Length::Type::Px);
};
auto solve_for_right = [&] {
return Length(containing_block.width() - left.to_px(*this) - margin_left.to_px(*this) - border_left.to_px(*this) - padding_left.to_px(*this) - width.to_px(*this) - padding_right.to_px(*this) - border_right.to_px(*this) - margin_right.to_px(*this), Length::Type::Px);
};
// 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 = Length(0, Length::Type::Px);
if (margin_right.is_auto())
margin_right = Length(0, Length::Type::Px);
// 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 = Length(0, Length::Type::Px);
goto Rule3;
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
if (!left.is_auto() && !width.is_auto() && !right.is_auto()) {
// FIXME: This should be solved in a more complicated way.
return width;
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
if (margin_left.is_auto())
margin_left = Length(0, Length::Type::Px);
if (margin_right.is_auto())
margin_right = Length(0, Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
// 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_width();
solve_for_left();
auto available_width = solve_for_width();
width = Length(min(max(result.preferred_minimum_width, available_width.to_px(*this)), result.preferred_width), Length::Type::Px);
}
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02: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();
}
LibHTML: Fetch the box edge values needed for block width computation.
2019-07-24 07:34:07 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
// 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_width();
right = solve_for_right();
auto available_width = solve_for_width();
width = Length(min(max(result.preferred_minimum_width, available_width.to_px(*this)), result.preferred_width), Length::Type::Px);
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
// 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();
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
// 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();
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
return width;
};
auto specified_width = style.length_or_fallback(CSS::PropertyID::Width, {}, containing_block.width());
// 1. The tentative used width is calculated (without 'min-width' and 'max-width')
auto used_width = try_compute_width(specified_width);
// 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'.
auto specified_max_width = style.length_or_fallback(CSS::PropertyID::MaxWidth, {}, containing_block.width());
if (!specified_max_width.is_auto()) {
if (used_width.to_px(*this) > specified_max_width.to_px(*this)) {
used_width = try_compute_width(specified_max_width);
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
}
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02: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'.
auto specified_min_width = style.length_or_fallback(CSS::PropertyID::MinWidth, {}, containing_block.width());
if (!specified_min_width.is_auto()) {
if (used_width.to_px(*this) < specified_min_width.to_px(*this)) {
used_width = try_compute_width(specified_min_width);
}
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
}
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
set_width(used_width.to_px(*this));
LibWeb: Make sure BoxModelMetrics are set for position:absolute boxes This is all very redundant and we should find a way to share this code between at least some of the positioning modes.
2020-06-23 19:20:31 +02:00
box_model().margin().left = margin_left;
box_model().margin().right = margin_right;
box_model().border().left = border_left;
box_model().border().right = border_right;
box_model().padding().left = padding_left;
box_model().padding().right = padding_right;
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
}
void LayoutBlock::compute_width()
{
if (is_absolutely_positioned())
return compute_width_for_absolutely_positioned_block();
auto& style = this->style();
LibHTML: Finish the block width calculation Also add horizontal box values to the layout tree dump.
2019-08-18 08:09:56 +02:00
auto auto_value = Length();
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
auto zero_value = Length(0, Length::Type::Px);
LibHTML: Fetch the box edge values needed for block width computation.
2019-07-24 07:34:07 +02:00
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
Length margin_left;
Length margin_right;
Length border_left;
Length border_right;
Length padding_left;
Length padding_right;
LibWeb: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
auto& containing_block = *this->containing_block();
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
auto try_compute_width = [&](const auto& a_width) {
Length width = a_width;
LibHTML: Hide debugging output unless HTML_DEBUG is defined
2019-09-25 12:42:10 +03:00
#ifdef HTML_DEBUG
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
dbg() << " Left: " << margin_left << "+" << border_left << "+" << padding_left;
dbg() << "Right: " << margin_right << "+" << border_right << "+" << padding_right;
LibHTML: Hide debugging output unless HTML_DEBUG is defined
2019-09-25 12:42:10 +03:00
#endif
LibWeb: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
margin_left = style.length_or_fallback(CSS::PropertyID::MarginLeft, zero_value, containing_block.width());
margin_right = style.length_or_fallback(CSS::PropertyID::MarginRight, zero_value, containing_block.width());
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
border_left = style.length_or_fallback(CSS::PropertyID::BorderLeftWidth, zero_value);
border_right = style.length_or_fallback(CSS::PropertyID::BorderRightWidth, zero_value);
LibWeb: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
padding_left = style.length_or_fallback(CSS::PropertyID::PaddingLeft, zero_value, containing_block.width());
padding_right = style.length_or_fallback(CSS::PropertyID::PaddingRight, zero_value, containing_block.width());
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
LibHTML: Use floating point numbers throughout the layout tree
2019-11-18 16:25:38 +01:00
float total_px = 0;
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
for (auto& value : { margin_left, border_left, padding_left, width, padding_right, border_right, margin_right }) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
total_px += value.to_px(*this);
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
}
LibHTML: A tiny bit of work towards block layout.
2019-07-26 08:05:14 +02:00
LibHTML: Hide debugging output unless HTML_DEBUG is defined
2019-09-25 12:42:10 +03:00
#ifdef HTML_DEBUG
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
dbg() << "Total: " << total_px;
LibHTML: Hide debugging output unless HTML_DEBUG is defined
2019-09-25 12:42:10 +03:00
#endif
LibHTML: A tiny bit of work towards block layout.
2019-07-26 08:05:14 +02:00
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
if (!is_replaced() && !is_inline()) {
// 10.3.3 Block-level, non-replaced elements in normal flow
// If 'width' is not 'auto' and 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' (plus any of 'margin-left' or 'margin-right' that are not 'auto') is larger than the width of the containing block, then any 'auto' values for 'margin-left' or 'margin-right' are, for the following rules, treated as zero.
if (width.is_auto() && total_px > containing_block.width()) {
if (margin_left.is_auto())
margin_left = zero_value;
if (margin_right.is_auto())
margin_right = zero_value;
}
LibHTML: Finish the block width calculation Also add horizontal box values to the layout tree dump.
2019-08-18 08:09:56 +02:00
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
// 10.3.3 cont'd.
auto underflow_px = containing_block.width() - total_px;
if (width.is_auto()) {
if (margin_left.is_auto())
margin_left = zero_value;
if (margin_right.is_auto())
margin_right = zero_value;
if (underflow_px >= 0) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
width = Length(underflow_px, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
} else {
width = zero_value;
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
margin_right = Length(margin_right.to_px(*this) + underflow_px, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
}
} else {
if (!margin_left.is_auto() && !margin_right.is_auto()) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
margin_right = Length(margin_right.to_px(*this) + underflow_px, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
} else if (!margin_left.is_auto() && margin_right.is_auto()) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
margin_right = Length(underflow_px, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
} else if (margin_left.is_auto() && !margin_right.is_auto()) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
margin_left = Length(underflow_px, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
} else { // margin_left.is_auto() && margin_right.is_auto()
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
auto half_of_the_underflow = Length(underflow_px / 2, Length::Type::Px);
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
margin_left = half_of_the_underflow;
margin_right = half_of_the_underflow;
}
}
} else if (!is_replaced() && is_inline_block()) {
// 10.3.9 'Inline-block', non-replaced elements in normal flow
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
// A computed value of 'auto' for 'margin-left' or 'margin-right' becomes a used value of '0'.
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
if (margin_left.is_auto())
margin_left = zero_value;
if (margin_right.is_auto())
margin_right = zero_value;
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
// If 'width' is 'auto', the used value is the shrink-to-fit width as for floating elements.
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
if (width.is_auto()) {
// Find the available width: in this case, this is the width of the containing
// block minus the used values of 'margin-left', 'border-left-width', 'padding-left',
// 'padding-right', 'border-right-width', 'margin-right', and the widths of any relevant scroll bars.
float available_width = containing_block.width()
- margin_left.to_px(*this) - border_left.to_px(*this) - padding_left.to_px(*this)
- padding_right.to_px(*this) - border_right.to_px(*this) - margin_right.to_px(*this);
auto result = calculate_shrink_to_fit_width();
// Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).
width = Length(min(max(result.preferred_minimum_width, available_width), result.preferred_width), Length::Type::Px);
}
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
}
LibWeb: Basic support for display:inline-block with width:auto We now implement the somewhat fuzzy shrink-to-fit algorithm when laying out inline-block elements with both block and inline children. Shrink-to-fit works by doing two speculative layouts of the entire subtree inside the current block, to compute two things: 1. Preferred minimum width: If we made a line break at every chance we had, how wide would the widest line be? 2. Preferred width: We break only when explicitly told to (e.g "<br>") How wide would the widest line be? We then shrink the width of the inline-block element to an appropriate value based on the above, taking the available width in the containing block into consideration (sans all the box model fluff.) To make the speculative layouts possible, plumb a LayoutMode enum throughout the layout system since it needs to be respected in various places. Note that this is quite hackish and I'm sure there are smarter ways to do a lot of this. But it does kinda work! :^)
2020-05-26 21:53:10 +02:00
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
return width;
};
LibWeb: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
auto specified_width = style.length_or_fallback(CSS::PropertyID::Width, auto_value, containing_block.width());
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
// 1. The tentative used width is calculated (without 'min-width' and 'max-width')
auto used_width = try_compute_width(specified_width);
// 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: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
auto specified_max_width = style.length_or_fallback(CSS::PropertyID::MaxWidth, auto_value, containing_block.width());
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
if (!specified_max_width.is_auto()) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
if (used_width.to_px(*this) > specified_max_width.to_px(*this)) {
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
used_width = try_compute_width(specified_max_width);
LibHTML: Finish the block width calculation Also add horizontal box values to the layout tree dump.
2019-08-18 08:09:56 +02:00
}
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +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: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
auto specified_min_width = style.length_or_fallback(CSS::PropertyID::MinWidth, auto_value, containing_block.width());
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
if (!specified_min_width.is_auto()) {
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
if (used_width.to_px(*this) < specified_min_width.to_px(*this)) {
LibHTML: Implement basic 'max-width' and 'min-width' support These CSS properties constrain the computed width of a block-level box to a maximum, followed by a minimum value. This makes the "better mother fricken website" look more like it's intended to (which helps makes the author's point, I suppose.)
2019-11-18 12:21:37 +01:00
used_width = try_compute_width(specified_min_width);
LibHTML: Finish the block width calculation Also add horizontal box values to the layout tree dump.
2019-08-18 08:09:56 +02:00
}
}
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
set_width(used_width.to_px(*this));
LibHTML: Rename ComputedStyle to BoxModelMetrics There was nothing left in ComputedStyle except the box model metrics, so this patch gives it a more representative name. Note that style information is fetched directly from StyleProperties, which is basically the CSS property name/value pairs that apply to an element.
2019-10-04 15:50:50 +02:00
box_model().margin().left = margin_left;
box_model().margin().right = margin_right;
box_model().border().left = border_left;
box_model().border().right = border_right;
box_model().padding().left = padding_left;
box_model().padding().right = padding_right;
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
void LayoutBlock::place_block_level_replaced_element_in_normal_flow(LayoutReplaced& box)
LibHTML: Implement basic block height computation ..and add vertical box properties to the layout tree dumps.
2019-08-18 08:37:53 +02:00
{
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
ASSERT(!is_absolutely_positioned());
auto& style = box.style();
LibWeb: Start fleshing out support for relative CSS units This patch introduces support for more than just "absolute px" units in our Length class. It now also supports "em" and "rem", which are units relative to the font-size of the current layout node and the <html> element's layout node respectively.
2020-06-07 17:55:46 +02:00
auto zero_value = Length(0, Length::Type::Px);
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
auto& containing_block = *this;
auto& replaced_element_box_model = box.box_model();
replaced_element_box_model.margin().top = style.length_or_fallback(CSS::PropertyID::MarginTop, zero_value, containing_block.width());
replaced_element_box_model.margin().bottom = style.length_or_fallback(CSS::PropertyID::MarginBottom, zero_value, containing_block.width());
replaced_element_box_model.border().top = style.length_or_fallback(CSS::PropertyID::BorderTopWidth, zero_value);
replaced_element_box_model.border().bottom = style.length_or_fallback(CSS::PropertyID::BorderBottomWidth, zero_value);
replaced_element_box_model.padding().top = style.length_or_fallback(CSS::PropertyID::PaddingTop, zero_value, containing_block.width());
replaced_element_box_model.padding().bottom = style.length_or_fallback(CSS::PropertyID::PaddingBottom, zero_value, containing_block.width());
LibWeb: Add basic support for CSS percentages Many properties can now have percentage values that get resolved in layout. The reference value (what is this a percentage *of*?) differs per property, so I've added a helper where you provide a reference value as an added parameter to the existing length_or_fallback().
2020-05-11 23:04:59 +02:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float x = replaced_element_box_model.margin().left.to_px(*this)
+ replaced_element_box_model.border().left.to_px(*this)
+ replaced_element_box_model.padding().left.to_px(*this)
+ replaced_element_box_model.offset().left.to_px(*this);
LibWeb: CSS: Add "position: absolute" with top and left This momentarily handles the CSS property "position: absolute;" in combination with the properties "top" and "left", so that elements can be placed anywhere on the page independently from their parents. Statically positioned elements ignore absolute positioned elements when calculating their position as they don't take up space.
2020-03-23 17:29:15 +01:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float y = replaced_element_box_model.margin_box(*this).top + box_model().offset().top.to_px(*this);
LibWeb: CSS: Add "position: absolute" with top and left This momentarily handles the CSS property "position: absolute;" in combination with the properties "top" and "left", so that elements can be placed anywhere on the page independently from their parents. Statically positioned elements ignore absolute positioned elements when calculating their position as they don't take up space.
2020-03-23 17:29:15 +01:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
box.set_offset(x, y);
}
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
LayoutBlock::ShrinkToFitResult LayoutBlock::calculate_shrink_to_fit_width()
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
{
auto greatest_child_width = [&] {
float max_width = 0;
if (children_are_inline()) {
for (auto& box : line_boxes()) {
max_width = max(max_width, box.width());
}
} else {
for_each_child([&](auto& child) {
if (child.is_box())
max_width = max(max_width, to<LayoutBox>(child).width());
});
}
return max_width;
};
// Calculate the preferred width by formatting the content without breaking lines
// other than where explicit line breaks occur.
layout_inside(LayoutMode::OnlyRequiredLineBreaks);
float preferred_width = greatest_child_width();
// Also calculate the preferred minimum width, e.g., by trying all possible line breaks.
// CSS 2.2 does not define the exact algorithm.
layout_inside(LayoutMode::AllPossibleLineBreaks);
float preferred_minimum_width = greatest_child_width();
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
return { preferred_width, preferred_minimum_width };
LibWeb: Better width computation for position:absolute blocks This patch basically translates the CSS2.2 spec language into C++ for computing the width of absolutely positioned non-replaced elements.
2020-06-18 18:28:32 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
void LayoutBlock::place_block_level_non_replaced_element_in_normal_flow(LayoutBlock& block)
{
auto& style = block.style();
auto zero_value = Length(0, Length::Type::Px);
auto& containing_block = *this;
auto& box = block.box_model();
box.margin().top = style.length_or_fallback(CSS::PropertyID::MarginTop, zero_value, containing_block.width());
box.margin().bottom = style.length_or_fallback(CSS::PropertyID::MarginBottom, zero_value, containing_block.width());
box.border().top = style.length_or_fallback(CSS::PropertyID::BorderTopWidth, zero_value);
box.border().bottom = style.length_or_fallback(CSS::PropertyID::BorderBottomWidth, zero_value);
box.padding().top = style.length_or_fallback(CSS::PropertyID::PaddingTop, zero_value, containing_block.width());
box.padding().bottom = style.length_or_fallback(CSS::PropertyID::PaddingBottom, zero_value, containing_block.width());
float x = box.margin().left.to_px(*this)
+ box.border().left.to_px(*this)
+ box.padding().left.to_px(*this)
+ box.offset().left.to_px(*this);
if (this->style().text_align() == CSS::ValueID::VendorSpecificCenter) {
x = (containing_block.width() / 2) - block.width() / 2;
LibWeb: Implement <center> as -libweb-center To get the expected behavior for <center>, we needed a special text alignment mode that centers block-level elements (and not just line box fragments.)
2020-06-13 10:54:58 +02:00
}
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float y = box.margin_box(*this).top
+ box.offset().top.to_px(*this);
LibWeb: CSS: Add "position: absolute" with top and left This momentarily handles the CSS property "position: absolute;" in combination with the properties "top" and "left", so that elements can be placed anywhere on the page independently from their parents. Statically positioned elements ignore absolute positioned elements when calculating their position as they don't take up space.
2020-03-23 17:29:15 +01:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
auto* relevant_sibling = block.previous_sibling();
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
while (relevant_sibling != nullptr) {
LibWeb: Cache the used CSS 'position' value on LayoutNodeWithStyle This avoids having to query the StyleProperties hash map whenever we need to know if an element is absolutely positioned. This was extremely hot in interactive window resize profiles.
2020-06-23 23:15:23 +02:00
if (relevant_sibling->position() != CSS::Position::Absolute)
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
break;
relevant_sibling = relevant_sibling->previous_sibling();
}
LibWeb: CSS: Add "position: absolute" with top and left This momentarily handles the CSS property "position: absolute;" in combination with the properties "top" and "left", so that elements can be placed anywhere on the page independently from their parents. Statically positioned elements ignore absolute positioned elements when calculating their position as they don't take up space.
2020-03-23 17:29:15 +01:00
LibWeb: Some improvements to absolute positioning Absolutely positioned blocks now register themselves with their containing block (and note that the containing block of an absolutely positioned box is the nearest non-statically positioned block ancestor or the ICB as fallback.) Containing blocks then drive the layout of their tracked absolutely positioned descendants as a separate layout pass. This is very far from perfect but the general direction seems good.
2020-06-12 13:27:28 +02:00
if (relevant_sibling) {
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
auto& sibling_box = relevant_sibling->box_model();
y += relevant_sibling->effective_offset().y() + relevant_sibling->height();
LibWeb: Implement very basic margin collapsing We now collapse a block's top margin with the previous sibling's bottom margin so that the larger margin wins.
2020-06-12 17:41:14 +02:00
// Collapse top margin with bottom margin of previous sibling if necessary
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
float previous_sibling_margin_bottom = sibling_box.margin().bottom.to_px(*relevant_sibling);
float my_margin_top = box.margin().top.to_px(*this);
LibWeb: Handle negative values when collapsing vertical margins In the presence of negative margins, we subtract the largest negative margin from max(0, largest positive margin).
2020-06-12 18:09:40 +02:00
if (my_margin_top < 0 || previous_sibling_margin_bottom < 0) {
// Negative margins present.
float largest_negative_margin = -min(my_margin_top, previous_sibling_margin_bottom);
float largest_positive_margin = (my_margin_top < 0 && previous_sibling_margin_bottom < 0) ? 0 : max(my_margin_top, previous_sibling_margin_bottom);
float final_margin = largest_positive_margin - largest_negative_margin;
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
y += final_margin - my_margin_top;
LibWeb: Handle negative values when collapsing vertical margins In the presence of negative margins, we subtract the largest negative margin from max(0, largest positive margin).
2020-06-12 18:09:40 +02:00
} else if (previous_sibling_margin_bottom > my_margin_top) {
LibWeb: Implement very basic margin collapsing We now collapse a block's top margin with the previous sibling's bottom margin so that the larger margin wins.
2020-06-12 17:41:14 +02:00
// Sibling's margin is larger than mine, adjust so we use sibling's.
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
y += previous_sibling_margin_bottom - my_margin_top;
LibWeb: Implement very basic margin collapsing We now collapse a block's top margin with the previous sibling's bottom margin so that the larger margin wins.
2020-06-12 17:41:14 +02:00
}
LibHTML: Fix LayoutBlock vertical position & height computations
2019-09-25 12:28:35 +03:00
}
LibWeb: CSS: Add "position: absolute" with top and left This momentarily handles the CSS property "position: absolute;" in combination with the properties "top" and "left", so that elements can be placed anywhere on the page independently from their parents. Statically positioned elements ignore absolute positioned elements when calculating their position as they don't take up space.
2020-03-23 17:29:15 +01:00
LibWeb: Reorganize layout algorithm Previously, layout recursively performed these steps (roughly): 1. Compute own width 2. Compute own position 3. Layout in-flow children 4. Compute own height 5. Layout absolutely positioned descendants However, step (2) was pretty inconsistent. Some things computed their own position, others had their parent do it for them, etc. To get closer to CSS spec language, and make things easier in general, this patch reorganizes the algorithm into: 1. Compute own width & height 2. Compute width & height of in-flow managed descendants 3. Move in-flow managed descendants to their final position 4. Layout absolutely positioned descendants Block layout is now driven by the containing block, which will iterate the descendants it's responsible for. There are a lot of inefficient patterns in this logic right now, but they can easily be replaced with better iteration functions once we settle on a long-term architecture. Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a containing block to move it into place. This code is still evolving along with my understanding of CSS layout, so it's likely that we'll reorganize this again sooner or later. :^)
2020-06-14 18:48:10 +02:00
block.set_offset(x, y);
LibHTML: Implement basic block height computation ..and add vertical box properties to the layout tree dumps.
2019-08-18 08:37:53 +02:00
}
LibHTML: Start fleshing out block layout. The basic idea of block layout is: width, then children based on width, then height based on height of children.
2019-07-01 07:28:37 +02:00
void LayoutBlock::compute_height()
{
LibHTML: Rename "style_properties" to "style" everywhere
2019-10-07 09:23:53 +02:00
auto& style = this->style();
LibWeb: Constrain block height by the max-height if specified
2020-06-10 15:28:56 +02:00
auto specified_height = style.length_or_fallback(CSS::PropertyID::Height, Length(), containing_block()->height());
auto specified_max_height = style.length_or_fallback(CSS::PropertyID::MaxHeight, Length(), containing_block()->height());
LibWeb: Make sure BoxModelMetrics are set for position:absolute boxes This is all very redundant and we should find a way to share this code between at least some of the positioning modes.
2020-06-23 19:20:31 +02:00
auto& containing_block = *this->containing_block();
box_model().margin().top = style.length_or_fallback(CSS::PropertyID::MarginTop, Length(0, Length::Type::Px), containing_block.width());
box_model().margin().bottom = style.length_or_fallback(CSS::PropertyID::MarginBottom, Length(0, Length::Type::Px), containing_block.width());
box_model().border().top = style.length_or_fallback(CSS::PropertyID::BorderTopWidth, Length(0, Length::Type::Px));
box_model().border().bottom = style.length_or_fallback(CSS::PropertyID::BorderBottomWidth, Length(0, Length::Type::Px));
box_model().padding().top = style.length_or_fallback(CSS::PropertyID::PaddingTop, Length(0, Length::Type::Px), containing_block.width());
box_model().padding().bottom = style.length_or_fallback(CSS::PropertyID::PaddingBottom, Length(0, Length::Type::Px), containing_block.width());
LibWeb: Constrain block height by the max-height if specified
2020-06-10 15:28:56 +02:00
if (!specified_height.is_auto()) {
float used_height = specified_height.to_px(*this);
if (!specified_max_height.is_auto())
used_height = min(used_height, specified_max_height.to_px(*this));
set_height(used_height);
}
LibHTML: Add layout() overrides for LayoutText and LayoutBlock.
2019-06-20 23:00:26 +02:00
}
LibHTML: Implement rendering
2019-09-25 12:40:37 +03:00
LibWeb: Rename LayoutNode::render() to paint() "Paint" matches what we call this in the rest of the system. Let's not confuse things by mixing paint/render/draw all the time. I'm guilty of this in more places.. Also rename RenderingContext => PaintContext.
2020-06-18 21:35:44 +02:00
void LayoutBlock::paint(PaintContext& context, PaintPhase phase)
LibHTML: Implement rendering
2019-09-25 12:40:37 +03:00
{
LibHTML: Implement the <blink> element Just in time for Serenity's 1st birthday, here is the <blink> element! This patch adds a bunch of different mechanisms to enable partial repaints of the layout tree (LayoutNode::set_needs_display())) It also adds LayoutNode::is_visible(), which can be toggled to prevent a LayoutNode from rendering anything (it still takes up space though.)
2019-10-09 21:25:29 +02:00
if (!is_visible())
return;
LibWeb: Rename LayoutNode::render() to paint() "Paint" matches what we call this in the rest of the system. Let's not confuse things by mixing paint/render/draw all the time. I'm guilty of this in more places.. Also rename RenderingContext => PaintContext.
2020-06-18 21:35:44 +02:00
LayoutBox::paint(context, phase);
LibHTML: Implement rendering
2019-09-25 12:40:37 +03:00
LibWeb: Separate layout tree rendering into phases CSS defines a very specific paint order. This patch starts steering us towards respecting that by introducing the PaintPhase enum with values: - Background - Border - Foreground - Overlay (internal overlays used by inspector) Basically, to get the right visual result, we have to render the page multiple times, going one phase at a time.
2020-06-18 18:57:35 +02:00
// FIXME: Inline backgrounds etc.
if (phase == PaintPhase::Foreground) {
if (children_are_inline()) {
for (auto& line_box : m_line_boxes) {
for (auto& fragment : line_box.fragments()) {
if (context.should_show_line_box_borders())
context.painter().draw_rect(enclosing_int_rect(fragment.absolute_rect()), Color::Green);
fragment.render(context);
}
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
}
}
}
LibGfx: Rename Rect,Point,Size => IntRect,IntPoint,IntSize This fits nicer with FloatRect,FloatPoint,FloatSize and gives a much better visual clue about what type of metric is being used.
2020-06-10 10:57:59 +02:00
HitTestResult LayoutBlock::hit_test(const Gfx::IntPoint& position) const
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
{
if (!children_are_inline())
LibHTML: LayoutBlock::hit_test() was calling the wrong parent class Oops, we now need to call LayoutBox instead of LayoutNode for blocks with non-inline children.
2019-10-15 22:02:11 +02:00
return LayoutBox::hit_test(position);
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
HitTestResult result;
for (auto& line_box : m_line_boxes) {
for (auto& fragment : line_box.fragments()) {
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
if (enclosing_int_rect(fragment.absolute_rect()).contains(position)) {
LibWeb: Make hit-testing work with display: inline-block; When hit testing encountered a block with inline children, we assumed that the inline children are nothing but text boxes. An inline-block box is actually a block child of a block with inline children, so we have to handle that scenario as well. :^) Fixes #2353.
2020-05-23 21:06:24 +02:00
if (fragment.layout_node().is_block())
return to<LayoutBlock>(fragment.layout_node()).hit_test(position);
LibHTML: Build some foundation for text selection Add LayoutPosition and LayoutRange classes. The layout tree root node now has a selection() LayoutRange. It's essentially a start and end LayoutPosition. A LayoutPosition is a LayoutNode, and an optional index into that node. The index is only relevant for text nodes, where it's the character index into the rendered text. HtmlView now updates the selection start/end of the LayoutDocument when clicking and dragging with the left mouse button. We don't paint the selection yet, and there's no way to copy what's selected. It only exists as a LayoutRange.
2019-11-05 22:13:26 +01:00
return { fragment.layout_node(), fragment.text_index_at(position.x()) };
LibHTML: Rewrite inline and text layout Inline layout is now done by LayoutBlock. Blocks with inline children will split them into line boxes during layout. A LayoutBlock can have zero or more LineBox objects. Each LineBox represents one visual line. A LineBox can have any number of LineBoxFragment children. A fragment is an offset+length into a specific LayoutNode. To paint a LayoutBlock with inline children, we walk its line boxes, and walk their fragments, painting each fragment at a time by calling LineBoxFragment::render(), which in turn calls the LayoutNode via LayoutText::render_fragment(). Hit testing works similarly. This is very incomplete and has many bugs, but should make it easier for us to move forward with this code.
2019-10-03 15:20:13 +02:00
}
}
}
LibWeb: Make hit testing better for blocks with inline children If we don't hit one of the inline children, we should still report that we've hit the block itself.
2020-03-20 12:41:31 +01:00
// FIXME: This should be smarter about the text position if we're hitting a block
// that has text inside it, but `position` is to the right of the text box.
LibWeb: Rework the layout engine to use relative offsets The box tree and line boxes now all store a relative offset from their containing block, instead of an absolute (document-relative) position. This removes a huge pain point from the layout system which was having to adjust offsets recursively when something moved. It also makes some layout logic significantly simpler. Every box can still find its absolute position by walking its chain of containing blocks and accumulating the translation from the root. This is currently what we do both for rendering and hit testing.
2020-06-10 10:42:29 +02:00
return { absolute_rect().contains(position.x(), position.y()) ? this : nullptr };
LibHTML: Implement rendering
2019-09-25 12:40:37 +03:00
}
LibHTML: Anonymous blocks *should* inherit some properties Okay, I got that a bit wrong. Here's what CSS 2.1 says: "The properties of anonymous boxes are inherited from the enclosing non-anonymous box. Non-inherited properties have their initial value." This patch implements a better behavior by only copying the inherited properties from the parent style.
2019-10-05 23:47:06 +02:00
NonnullRefPtr<StyleProperties> LayoutBlock::style_for_anonymous_block() const
{
auto new_style = StyleProperties::create();
LibHTML: Use an enum for CSS property ID's Instead of using string everywhere, have the CSS parser produce enum values, since they are a lot nicer to work with. In the future we should generate most of this code based on a list of supported CSS properties.
2019-10-08 15:34:19 +02:00
style().for_each_property([&](auto property_id, auto& value) {
if (StyleResolver::is_inherited_property(property_id))
new_style->set_property(property_id, value);
LibHTML: Anonymous blocks *should* inherit some properties Okay, I got that a bit wrong. Here's what CSS 2.1 says: "The properties of anonymous boxes are inherited from the enclosing non-anonymous box. Non-inherited properties have their initial value." This patch implements a better behavior by only copying the inherited properties from the parent style.
2019-10-05 23:47:06 +02:00
});
return new_style;
}
LibHTML: Fix broken line splitting behavior in LayoutReplaced Replaced elements will now properly create line breaks when they use up the available horizontal space. This fixes an issue with <img>'s lining up instead of breaking.
2019-10-13 17:24:00 +02:00
LineBox& LayoutBlock::ensure_last_line_box()
{
if (m_line_boxes.is_empty())
m_line_boxes.append(LineBox());
return m_line_boxes.last();
}
LineBox& LayoutBlock::add_line_box()
{
m_line_boxes.append(LineBox());
return m_line_boxes.last();
}
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
void LayoutBlock::split_into_lines(LayoutBlock& container, LayoutMode layout_mode)
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
{
LibWeb: LayoutMode line_break_policy => LayoutMode layout_mode
2020-05-27 19:20:49 +02:00
layout(layout_mode);
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
auto* line_box = &container.ensure_last_line_box();
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
if (layout_mode != LayoutMode::OnlyRequiredLineBreaks && line_box->width() > 0 && line_box->width() + width() > container.width()) {
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
line_box = &container.add_line_box();
LibWeb: More work on width of position:absolute elements The shrink-to-fit width algorithm actually works a little bit different in the absolute positioning context, so it can't share all of its code with non-absolute positioning. Also, inline-block elements were always inserting unnecessary line breaks when splitting, which caused the preferred width to be smaller than it should be. This patch fixes that as well, by just not breaking after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
2020-06-18 21:16:29 +02:00
}
LibWeb: Add support for "display: inline-block" This display type is implemented using a LayoutBlock that is_inline(). Basically it behaves like a block internally, and its children are laid out in the normal block layout fashion. Externally however, it behaves like an atomic inline-level box. Layout of inline-block boxes happens in three stages: 1. The outer dimensions of the block are computed during the recursive normal layout pass. We skip positioning, but lay out children. 2. Later on, during line layout in the *containing block*, the inline block now contributes a linebox fragment. When linebox fragments are positioned, we learn the final position of the inline block. That's when we set the inline block's position. 3. We re-layout the inline block's children once again. This is done to make sure they end up in the right position. The layout tree doesn't use relative offsets, so after we position the inline block in (2), its children will not have its positions updated. Relayout moves all children of inline blocks to the right place. This is a rather naive approach but it does get the basic behavior into place so we can iterate on it. :^)
2020-05-05 16:06:22 +02:00
line_box->add_fragment(*this, 0, 0, width(), height());
}
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink