Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-02 14:20:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/LayoutBlock.h

129 lines
4.4 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.
*/
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
#pragma once
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/LayoutBox.h>
#include <LibWeb/Layout/LineBox.h>
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
namespace Web {
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
class Element;
LibHTML: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
class LayoutBlock : public LayoutBox {
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
public:
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
LayoutBlock(Document&, const Node*, NonnullRefPtr<StyleProperties>);
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
virtual ~LayoutBlock() override;
virtual const char* class_name() const override { return "LayoutBlock"; }
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
virtual void layout(LayoutMode = LayoutMode::Default) override;
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
virtual void paint(PaintContext&, PaintPhase) override;
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
virtual LayoutNode& inline_wrapper() override;
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
Vector<LineBox>& line_boxes() { return m_line_boxes; }
const Vector<LineBox>& line_boxes() const { return m_line_boxes; }
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& ensure_last_line_box();
LineBox& add_line_box();
LibGfx: Rename Rect,Point,Size => IntRect,IntPoint,IntSize This fits nicer with FloatRect,FloatPoint,FloatSize and gives a much better visual clue about what type of metric is being used.
2020-06-10 10:57:59 +02:00
virtual HitTestResult hit_test(const Gfx::IntPoint&) const override;
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: Introduce LayoutBox and LayoutNodeWithStyleAndBoxModelMetrics To streamline the layout tree and remove irrelevant data from classes that don't need it, this patch adds two new LayoutNode subclasses. LayoutNodeWithStyleAndBoxModelMetrics should be inherited by any layout node that cares about box model metrics (margin, border, and padding.) LayoutBox should be inherited by any layout node that can have a rect. This makes LayoutText significantly smaller (from 140 to 40 bytes) and clarifies a lot of things about the layout tree. I'm also adding next_sibling() and previous_sibling() overloads to LayoutBlock that return a LayoutBlock*. This is okay since blocks only ever have block siblings. Do also note that the semantics of is<T> slightly change in this patch: is<T>(nullptr) now returns true, to facilitate allowing to<T>(nullptr).
2019-10-15 16:48:38 +02:00
LayoutBlock* previous_sibling() { return to<LayoutBlock>(LayoutNode::previous_sibling()); }
const LayoutBlock* previous_sibling() const { return to<LayoutBlock>(LayoutNode::previous_sibling()); }
LayoutBlock* next_sibling() { return to<LayoutBlock>(LayoutNode::next_sibling()); }
const LayoutBlock* next_sibling() const { return to<LayoutBlock>(LayoutNode::next_sibling()); }
LibHTML+Browser: Support scrolling to anchor with <a href="#foo"> This patch implements basic support for <a href="#foo"> fragment links. To figure out where we actually want to scroll to, we have to do something different based on the layout node's box type. So if it's a regular LayoutBox we can just use the LayoutBox::position(). However, if it's an inline layout node, we use the position of the first line box fragment in the containing block contributed by this layout node or one of its descendants.
2019-10-20 09:14:12 +02:00
template<typename Callback>
void for_each_fragment(Callback);
template<typename Callback>
void for_each_fragment(Callback) const;
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
virtual void split_into_lines(LayoutBlock& container, LayoutMode) override;
LibWeb: Layout table-cell contents once again once final width is known This makes centered and right-aligned table-cell contents position itself correctly.
2020-06-28 20:09:41 +02:00
void layout_inside(LayoutMode);
LibWeb: Add LayoutTableRowGroup to implement display: table-row-group
2020-06-09 21:08:15 +02:00
protected:
void compute_width();
void compute_height();
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
void layout_absolutely_positioned_descendants();
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: 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
virtual float width_of_logical_containing_block() const;
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
private:
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
virtual bool is_block() const override { return true; }
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
struct ShrinkToFitResult {
float preferred_width { 0 };
float preferred_minimum_width { 0 };
};
ShrinkToFitResult 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
void compute_width_for_absolutely_positioned_block();
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 place_block_level_non_replaced_element_in_normal_flow(LayoutBlock&);
void place_block_level_replaced_element_in_normal_flow(LayoutReplaced&);
void layout_absolutely_positioned_descendant(LayoutBox&);
LibHTML: Anonymous blocks *should* inherit some properties Okay, I got that a bit wrong. Here's what CSS 2.1 says: "The properties of anonymous boxes are inherited from the enclosing non-anonymous box. Non-inherited properties have their initial value." This patch implements a better behavior by only copying the inherited properties from the parent style.
2019-10-05 23:47:06 +02:00
NonnullRefPtr<StyleProperties> style_for_anonymous_block() const;
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
void layout_inline_children(LayoutMode);
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 layout_contained_boxes(LayoutMode);
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
Vector<LineBox> m_line_boxes;
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02: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
template<typename Callback>
LibHTML+Browser: Support scrolling to anchor with <a href="#foo"> This patch implements basic support for <a href="#foo"> fragment links. To figure out where we actually want to scroll to, we have to do something different based on the layout node's box type. So if it's a regular LayoutBox we can just use the LayoutBox::position(). However, if it's an inline layout node, we use the position of the first line box fragment in the containing block contributed by this layout node or one of its descendants.
2019-10-20 09:14:12 +02:00
void LayoutBlock::for_each_fragment(Callback callback)
{
for (auto& line_box : line_boxes()) {
for (auto& fragment : line_box.fragments()) {
if (callback(fragment) == IterationDecision::Break)
return;
}
}
}
template<typename Callback>
void LayoutBlock::for_each_fragment(Callback callback) const
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
{
LibHTML+Browser: Support scrolling to anchor with <a href="#foo"> This patch implements basic support for <a href="#foo"> fragment links. To figure out where we actually want to scroll to, we have to do something different based on the layout node's box type. So if it's a regular LayoutBox we can just use the LayoutBox::position(). However, if it's an inline layout node, we use the position of the first line box fragment in the containing block contributed by this layout node or one of its descendants.
2019-10-20 09:14:12 +02:00
for (auto& line_box : line_boxes()) {
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
for (auto& fragment : line_box.fragments()) {
if (callback(fragment) == IterationDecision::Break)
return;
}
}
}
LibHTML: Add is<T> and to<T> helpers for LayoutNode class family
2019-10-15 14:19:52 +02:00
template<>
LibWeb: Always inline is<LayoutBox>() and is<LayoutBlock>()
2020-06-23 23:21:39 +02:00
ALWAYS_INLINE bool is<LayoutBlock>(const LayoutNode& node)
LibHTML: Add is<T> and to<T> helpers for LayoutNode class family
2019-10-15 14:19:52 +02:00
{
return node.is_block();
}
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
}
Reference in a new issue Copy permalink