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

782 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 {
LibWeb: Make layout tree have non-const pointers to the DOM Const pointers into the DOM was a nice idea, but in practice, there are too many situations where the layout tree wants to some non-const thing to the DOM.
2020-07-28 19:48:57 +02:00
LayoutBlock::LayoutBlock(DOM::Document& document, DOM::Node* node, NonnullRefPtr<CSS::StyleProperties> style)
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
: LayoutBox(document, 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) {
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
append_child(adopt(*new LayoutBlock(document(), 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();
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto zero_value = CSS::Length::make_px(0);
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: Move width into LayoutStyle This patch also adds the ability for Length to contain percentage values. This is a little off-spec, but will make storing and dealing with lengths a lot easier. To resolve a Length to a px-or-auto Length, there are now helpers for that. After calling them, you no longer have to think about em, rem, %, and such things.
2020-06-24 15:38:21 +02:00
auto specified_width = box.style().width().resolved_or_auto(box, 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: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box_model.margin.left = box.style().margin().left.resolved_or_auto(box, width());
box_model.margin.top = box.style().margin().top.resolved_or_auto(box, height());
box_model.margin.right = box.style().margin().right.resolved_or_auto(box, width());
box_model.margin.bottom = box.style().margin().bottom.resolved_or_auto(box, height());
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
box_model.border.left = CSS::Length::make_px(box.style().border_left().width);
box_model.border.right = CSS::Length::make_px(box.style().border_right().width);
box_model.border.top = CSS::Length::make_px(box.style().border_top().width);
box_model.border.bottom = CSS::Length::make_px(box.style().border_bottom().width);
LibWeb: Update the border metrics of absolutely positioned boxes We were neglecting to populate the border parts of BoxModelMetrics for absolutely positioned block descendants.
2020-06-25 12:56:20 +02:00
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box_model.offset.left = box.style().offset().left.resolved_or_auto(box, width());
box_model.offset.top = box.style().offset().top.resolved_or_auto(box, height());
box_model.offset.right = box.style().offset().right.resolved_or_auto(box, width());
box_model.offset.bottom = box.style().offset().bottom.resolved_or_auto(box, height());
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +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: 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: 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;
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
if (!box_model.offset.left.is_auto()) {
float x_offset = box_model.offset.left.to_px(box)
+ box_model.border_box(box).left;
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
used_offset.set_x(x_offset + box_model.margin.left.to_px(box));
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
} else if (!box_model.offset.right.is_auto()) {
float x_offset = 0
- box_model.offset.right.to_px(box)
- box_model.border_box(box).right;
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
used_offset.set_x(width() + x_offset - box.width() - box_model.margin.right.to_px(box));
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
} else {
float x_offset = box_model.margin_box(box).left;
used_offset.set_x(x_offset);
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: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
if (!box_model.offset.top.is_auto()) {
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
float y_offset = box_model.offset.top.to_px(box)
+ box_model.border_box(box).top;
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
used_offset.set_y(y_offset + box_model.margin.top.to_px(box));
} else if (!box_model.offset.bottom.is_auto()) {
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
float y_offset = 0
- box_model.offset.bottom.to_px(box)
- box_model.border_box(box).bottom;
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
used_offset.set_y(height() + y_offset - box.height() - box_model.margin.bottom.to_px(box));
LibWeb: Iterating more on placement of absolutely positioned elements
2020-06-25 15:00:30 +02:00
} else {
float y_offset = box_model.margin_box(box).top;
used_offset.set_y(y_offset);
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(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())
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
place_block_level_replaced_element_in_normal_flow(downcast<LayoutReplaced>(box));
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
else if (box.is_block())
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
place_block_level_non_replaced_element_in_normal_flow(downcast<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);
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
content_width = max(content_width, downcast<LayoutBox>(box).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
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) {
LibWeb: Move width into LayoutStyle This patch also adds the ability for Length to contain percentage values. This is a little off-spec, but will make storing and dealing with lengths a lot easier. To resolve a Length to a px-or-auto Length, there are now helpers for that. After calling them, you no longer have to think about em, rem, %, and such things.
2020-06-24 15:38:21 +02:00
if (style().width().is_undefined() || style().width().is_auto())
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
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: Remove empty trailing line boxes Sometimes we end up with an empty line box at the bottom of a block. Instead of worrying about this in all the places we split into lines, just remove the trailing box (if any) after splitting is finshed.
2020-06-25 12:40:07 +02:00
// If there's an empty line box at the bottom, just remove it instead of giving it height.
if (!m_line_boxes.is_empty() && m_line_boxes.last().fragments().is_empty())
m_line_boxes.take_last();
LibWeb: Move position and text-align to LayoutStyle
2020-06-24 14:34:40 +02:00
auto text_align = style().text_align();
LibWeb: Rename LayoutNode::style() => specified_style() Let's make way for a slightly-more-cooked style() that will eventually replace the raw specified_style() for layout and paint purposes.
2020-06-24 13:51:14 +02:00
float min_line_height = specified_style().line_height(*this);
float line_spacing = min_line_height - specified_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) {
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
case CSS::TextAlign::Center:
case CSS::TextAlign::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;
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
case CSS::TextAlign::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;
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
case CSS::TextAlign::Left:
case CSS::TextAlign::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;
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
if (text_align == CSS::TextAlign::Justify) {
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
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
LibWeb: Cache the used CSS text-align property on LayoutNodeWithStyle
2020-06-23 23:28:40 +02:00
if (text_align == CSS::TextAlign::Justify) {
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 (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()) {
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
auto& inline_block = const_cast<LayoutBlock&>(downcast<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
{
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();
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto zero_value = CSS::Length::make_px(0);
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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto margin_left = CSS::Length::make_auto();
auto margin_right = CSS::Length::make_auto();
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
const auto border_left = style().border_left().width;
const auto border_right = style().border_right().width;
LibWeb: Avoid some redundant resolution of padding values during layout Padding is not affected by the width constraining algorithm, so we can just resolve it up front.
2020-06-25 12:14:26 +02:00
const auto padding_left = style().padding().left.resolved(zero_value, *this, containing_block.width());
const auto padding_right = style().padding().right.resolved(zero_value, *this, containing_block.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
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: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
margin_left = style().margin().left.resolved(zero_value, *this, containing_block.width());
margin_right = style().margin().right.resolved(zero_value, *this, containing_block.width());
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
auto left = style().offset().left.resolved_or_auto(*this, containing_block.width());
auto right = style().offset().right.resolved_or_auto(*this, containing_block.width());
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
auto width = a_width;
auto solve_for_left = [&] {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
return CSS::Length(containing_block.width() - margin_left.to_px(*this) - border_left - padding_left.to_px(*this) - width.to_px(*this) - padding_right.to_px(*this) - border_right - margin_right.to_px(*this) - right.to_px(*this), CSS::Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
};
auto solve_for_width = [&] {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
return CSS::Length(containing_block.width() - left.to_px(*this) - margin_left.to_px(*this) - border_left - padding_left.to_px(*this) - padding_right.to_px(*this) - border_right - margin_right.to_px(*this) - right.to_px(*this), CSS::Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
};
auto solve_for_right = [&] {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
return CSS::Length(containing_block.width() - left.to_px(*this) - margin_left.to_px(*this) - border_left - padding_left.to_px(*this) - width.to_px(*this) - padding_right.to_px(*this) - border_right - margin_right.to_px(*this), CSS::Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
};
// If all three of 'left', 'width', and 'right' are 'auto':
if (left.is_auto() && width.is_auto() && right.is_auto()) {
// First set any 'auto' values for 'margin-left' and 'margin-right' to 0.
if (margin_left.is_auto())
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_left = CSS::Length::make_px(0);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
if (margin_right.is_auto())
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_right = CSS::Length::make_px(0);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
// 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.
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
left = CSS::Length::make_px(0);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
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())
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_left = CSS::Length::make_px(0);
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_right.is_auto())
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_right = CSS::Length::make_px(0);
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
// 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();
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
width = CSS::Length(min(max(result.preferred_minimum_width, available_width.to_px(*this)), result.preferred_width), CSS::Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +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
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();
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
width = CSS::Length(min(max(result.preferred_minimum_width, available_width.to_px(*this)), result.preferred_width), CSS::Length::Type::Px);
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +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
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;
};
LibWeb: Move width into LayoutStyle This patch also adds the ability for Length to contain percentage values. This is a little off-spec, but will make storing and dealing with lengths a lot easier. To resolve a Length to a px-or-auto Length, there are now helpers for that. After calling them, you no longer have to think about em, rem, %, and such things.
2020-06-24 15:38:21 +02:00
auto specified_width = style().width().resolved_or_auto(*this, containing_block.width());
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02: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: Move min-width and max-width into LayoutStyle
2020-06-24 16:03:25 +02:00
auto specified_max_width = style().max_width().resolved_or_auto(*this, containing_block.width());
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
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'.
LibWeb: Move min-width and max-width into LayoutStyle
2020-06-24 16:03:25 +02:00
auto specified_min_width = style().min_width().resolved_or_auto(*this, containing_block.width());
LibWeb: Respect min-width and max-width on position:absolute elements
2020-06-18 21:30:19 +02:00
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
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
box_model().margin.left = margin_left;
box_model().margin.right = margin_right;
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
box_model().border.left = CSS::Length::make_px(border_left);
box_model().border.right = CSS::Length::make_px(border_right);
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
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
}
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
float LayoutBlock::width_of_logical_containing_block() const
{
auto* containing_block = this->containing_block();
ASSERT(containing_block);
return containing_block->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
void LayoutBlock::compute_width()
{
if (is_absolutely_positioned())
return compute_width_for_absolutely_positioned_block();
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
float width_of_containing_block = this->width_of_logical_containing_block();
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto zero_value = CSS::Length::make_px(0);
LibHTML: Fetch the box edge values needed for block width computation.
2019-07-24 07:34:07 +02:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto margin_left = CSS::Length::make_auto();
auto margin_right = CSS::Length::make_auto();
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
const auto padding_left = style().padding().left.resolved_or_zero(*this, width_of_containing_block);
const auto padding_right = style().padding().right.resolved_or_zero(*this, width_of_containing_block);
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
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) {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
CSS::Length width = a_width;
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
margin_left = style().margin().left.resolved_or_zero(*this, width_of_containing_block);
margin_right = style().margin().right.resolved_or_zero(*this, width_of_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
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
float total_px = style().border_left().width + style().border_right().width;
for (auto& value : { margin_left, padding_left, width, padding_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.
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
if (width.is_auto() && total_px > width_of_containing_block) {
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 (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.
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
auto underflow_px = width_of_containing_block - total_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
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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
width = CSS::Length(underflow_px, CSS::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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_right = CSS::Length(margin_right.to_px(*this) + underflow_px, CSS::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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_right = CSS::Length(margin_right.to_px(*this) + underflow_px, CSS::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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_right = CSS::Length(underflow_px, CSS::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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
margin_left = CSS::Length(underflow_px, CSS::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: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto half_of_the_underflow = CSS::Length(underflow_px / 2, CSS::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.
LibWeb: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
float available_width = width_of_containing_block
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
- margin_left.to_px(*this) - style().border_left().width - padding_left.to_px(*this)
- padding_right.to_px(*this) - style().border_right().width - margin_right.to_px(*this);
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
auto result = calculate_shrink_to_fit_width();
// Then the shrink-to-fit width is: min(max(preferred minimum width, available width), preferred width).
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
width = CSS::Length(min(max(result.preferred_minimum_width, available_width), result.preferred_width), CSS::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
}
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: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
auto specified_width = style().width().resolved_or_auto(*this, width_of_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
// 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: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
auto specified_max_width = style().max_width().resolved_or_auto(*this, width_of_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
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: Start working on supporting fixed table layouts Sometimes people make tables with a specific width. In those cases, we can't just use the auto-sizing algorithm, but instead have to respect whatever width the content specifies. This is a bit rickety right now, since we don't implement generation of anonymous table boxes. The basic mechanism here is that block layout (which table-cell uses) now has a virtual way of asking for the width of the logical containing block. This is necessary as table-row does not produce a block-level element and so was previously unable to provide a containing block width for table-cell layout. If the table has a non-auto specified width, we now interpret that as a request to use fixed table layout. This will evolve over time. :^)
2020-06-28 15:11:08 +02:00
auto specified_min_width = style().min_width().resolved_or_auto(*this, width_of_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
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));
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
box_model().margin.left = margin_left;
box_model().margin.right = margin_right;
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
box_model().border.left = CSS::Length::make_px(style().border_left().width);
box_model().border.right = CSS::Length::make_px(style().border_right().width);
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
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& containing_block = *this;
auto& replaced_element_box_model = box.box_model();
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
replaced_element_box_model.margin.top = box.style().margin().top.resolved_or_zero(*this, containing_block.width());
replaced_element_box_model.margin.bottom = box.style().margin().bottom.resolved_or_zero(*this, containing_block.width());
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
replaced_element_box_model.border.top = CSS::Length::make_px(box.style().border_top().width);
replaced_element_box_model.border.bottom = CSS::Length::make_px(box.style().border_bottom().width);
LibWeb: Move border width and color into LayoutStyle To make this possible, I also had to give each LayoutNode a Document& so it can resolve document-specific colors correctly. There's probably ways to avoid having this extra member by resolving colors later, but this works for now.
2020-06-24 19:41:12 +02:00
replaced_element_box_model.padding.top = box.style().padding().top.resolved_or_zero(*this, containing_block.width());
replaced_element_box_model.padding.bottom = box.style().padding().bottom.resolved_or_zero(*this, 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: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +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: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +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())
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
max_width = max(max_width, downcast<LayoutBox>(child).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
});
}
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)
{
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto zero_value = CSS::Length::make_px(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
auto& containing_block = *this;
auto& box = block.box_model();
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
auto& style = block.style();
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: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box.margin.top = style.margin().top.resolved(zero_value, *this, containing_block.width());
box.margin.bottom = style.margin().bottom.resolved(zero_value, *this, containing_block.width());
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
box.border.top = CSS::Length::make_px(style.border_top().width);
box.border.bottom = CSS::Length::make_px(style.border_bottom().width);
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box.padding.top = style.padding().top.resolved(zero_value, *this, containing_block.width());
box.padding.bottom = style.padding().bottom.resolved(zero_value, *this, containing_block.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: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
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);
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: Move position and text-align to LayoutStyle
2020-06-24 14:34:40 +02:00
if (this->style().text_align() == CSS::TextAlign::VendorSpecificCenter) {
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
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
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
+ 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: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
// NOTE: Empty (0-height) preceding siblings have their margins collapsed with *their* preceding sibling, etc.
float collapsed_bottom_margin_of_preceding_siblings = 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
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: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
if (!relevant_sibling->is_absolutely_positioned() && !relevant_sibling->is_floating()) {
collapsed_bottom_margin_of_preceding_siblings = max(collapsed_bottom_margin_of_preceding_siblings, relevant_sibling->box_model().margin.bottom.to_px(*relevant_sibling));
if (relevant_sibling->height() > 0)
break;
}
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
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
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
LibWeb: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
// Collapse top margin with bottom margin of preceding siblings if needed
LibWeb: Turn BoxModelMetrics into a simple struct Using getters for this thing was just cumbersome and didn't achieve anything of value so just turn it into a plain struct.
2020-06-24 11:22:34 +02:00
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
LibWeb: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
if (my_margin_top < 0 || collapsed_bottom_margin_of_preceding_siblings < 0) {
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
// Negative margins present.
LibWeb: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
float largest_negative_margin = -min(my_margin_top, collapsed_bottom_margin_of_preceding_siblings);
float largest_positive_margin = (my_margin_top < 0 && collapsed_bottom_margin_of_preceding_siblings < 0) ? 0 : max(my_margin_top, collapsed_bottom_margin_of_preceding_siblings);
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
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: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
} else if (collapsed_bottom_margin_of_preceding_siblings > 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: Collapse top and bottom margin of empty sibling blocks Margin collapsing is a bit confusing, but if I understand correctly, when collapsing a box's top margin with the vertically adjacent sibling box above, we should "skip over" empty (0-height) boxes and collapse their margin with *their* vertically adjacent sibling box above, etc. Iterating until we hit the first non-empty in-flow block. This pulls up the bottom part of the face on ACID2. :^)
2020-06-28 10:51:11 +02:00
y += collapsed_bottom_margin_of_preceding_siblings - 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()
{
LibWeb: Move height, min-height and max-height into LayoutStyle
2020-06-24 16:11:15 +02:00
auto& containing_block = *this->containing_block();
LibWeb: Constrain block height by the max-height if specified
2020-06-10 15:28:56 +02:00
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
CSS::Length specified_height;
LibWeb: Percentage 'height' should sometimes behave as 'auto' Something like "height: 50%" is equivalent to "height: auto" unless the containing block has explicitly specified height.
2020-06-25 16:04:57 +02:00
if (style().height().is_percentage() && !containing_block.style().height().is_absolute()) {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
specified_height = CSS::Length::make_auto();
LibWeb: Percentage 'height' should sometimes behave as 'auto' Something like "height: 50%" is equivalent to "height: auto" unless the containing block has explicitly specified height.
2020-06-25 16:04:57 +02:00
} else {
specified_height = style().height().resolved_or_auto(*this, containing_block.height());
}
LibWeb: Move height, min-height and max-height into LayoutStyle
2020-06-24 16:11:15 +02:00
auto specified_max_height = style().max_height().resolved_or_auto(*this, containing_block.height());
LibWeb: Constrain block height by the max-height if specified
2020-06-10 15:28:56 +02:00
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box_model().margin.top = style().margin().top.resolved_or_zero(*this, containing_block.width());
box_model().margin.bottom = style().margin().bottom.resolved_or_zero(*this, containing_block.width());
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
box_model().border.top = CSS::Length::make_px(style().border_top().width);
box_model().border.bottom = CSS::Length::make_px(style().border_bottom().width);
LibWeb: Move the offset, margin and padding boxes into LayoutStyle
2020-06-24 17:45:42 +02:00
box_model().padding.top = style().padding().top.resolved_or_zero(*this, containing_block.width());
box_model().padding.bottom = style().padding().bottom.resolved_or_zero(*this, containing_block.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
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);
LibWeb: Rename LineBoxFragment::render() => paint() Also LayoutText::render_fragment() => render(). This matches the names in the rest of LibWeb.
2020-06-28 23:07:44 +02:00
fragment.paint(context);
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
}
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: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
HitTestResult LayoutBlock::hit_test(const Gfx::IntPoint& position, HitTestType type) 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())
LibWeb: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
return LayoutBox::hit_test(position, type);
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: Improve hit testing on the right of line boxes We now remember the last candidate fragment when hit testing past the right end of text and use that as the fallback result if nothing else matches. This makes it possible to drag-select outside the line boxes in a way that feels mostly natural. :^)
2020-06-29 00:37:39 +02:00
HitTestResult last_good_candidate;
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) {
for (auto& fragment : line_box.fragments()) {
LibWeb: Switch to using AK::is and AK::downcast
2020-07-26 17:16:18 +02:00
if (is<LayoutBox>(fragment.layout_node()) && downcast<LayoutBox>(fragment.layout_node()).stacking_context())
LibWeb: Use the StackingContext tree for hit testing This makes it possible to click links that are above other content due to stacking context order (e.g via CSS z-index.)
2020-07-01 19:02:28 +02:00
continue;
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())
LibWeb: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
return downcast<LayoutBlock>(fragment.layout_node()).hit_test(position, type);
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: Improve hit testing on the right of line boxes We now remember the last candidate fragment when hit testing past the right end of text and use that as the fallback result if nothing else matches. This makes it possible to drag-select outside the line boxes in a way that feels mostly natural. :^)
2020-06-29 00:37:39 +02:00
if (fragment.absolute_rect().top() <= position.y())
last_good_candidate = { 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
LibWeb: Specialize hit testing for text cursor purposes The text cursor follows slightly different "intuitive" rules than the regular hit testing. Clicking past the right edge of a text box should still "hit" the text box, and place the cursor at its end, for example. We solve this by adding a HitTestType enum that is passed to hit_test() and determines whether past-the-edge candidates are considered.
2020-08-05 16:55:56 +02:00
if (type == HitTestType::TextCursor && last_good_candidate.layout_node)
LibWeb: Improve hit testing on the right of line boxes We now remember the last candidate fragment when hit testing past the right end of text and use that as the fallback result if nothing else matches. This makes it possible to drag-select outside the line boxes in a way that feels mostly natural. :^)
2020-06-29 00:37:39 +02:00
return last_good_candidate;
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
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
NonnullRefPtr<CSS::StyleProperties> LayoutBlock::style_for_anonymous_block() const
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
{
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
auto new_style = CSS::StyleProperties::create();
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
LibWeb: Rename LayoutNode::style() => specified_style() Let's make way for a slightly-more-cooked style() that will eventually replace the raw specified_style() for layout and paint purposes.
2020-06-24 13:51:14 +02:00
specified_style().for_each_property([&](auto property_id, auto& value) {
LibWeb: Move CSS classes into the Web::CSS namespace
2020-07-26 20:01:35 +02:00
if (CSS::StyleResolver::is_inherited_property(property_id))
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
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