Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Layout/InitialContainingBlock.h

41 lines
1.1 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
/*
LibWeb: Rename InitialContainingBlockBox => InitialContainingBlock The "Box" suffix added nothing here.
2021-09-08 11:27:46 +02:00
* Copyright (c) 2018-2021, Andreas Kling <kling@serenityos.org>
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
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
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
*/
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/DOM/Document.h>
LibWeb: Rename Layout::BlockBox => BlockContainer There's a subtle difference here. A "block box" in the spec is a block-level box, while a "block container" is a box whose children are either all inline-level boxes in an IFC, or all block-level boxes participating in a BFC. Notably, an "inline-block" box is a "block container" but not a "block box" since it is itself inline-level.
2021-10-06 20:02:41 +02:00
#include <LibWeb/Layout/BlockContainer.h>
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
namespace Web::Layout {
LibWeb: Move everything into the Web namespace
2020-03-07 10:27:02 +01:00
LibWeb: Rename Layout::BlockBox => BlockContainer There's a subtle difference here. A "block box" in the spec is a block-level box, while a "block container" is a box whose children are either all inline-level boxes in an IFC, or all block-level boxes participating in a BFC. Notably, an "inline-block" box is a "block container" but not a "block box" since it is itself inline-level.
2021-10-06 20:02:41 +02:00
class InitialContainingBlock final : public BlockContainer {
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
public:
LibWeb: Rename InitialContainingBlockBox => InitialContainingBlock The "Box" suffix added nothing here.
2021-09-08 11:27:46 +02:00
explicit InitialContainingBlock(DOM::Document&, NonnullRefPtr<CSS::StyleProperties>);
virtual ~InitialContainingBlock() override;
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
LibWeb: Rename LayoutNode classes and move them into Layout namespace Bring the names of various boxes closer to spec language. This should hopefully make things easier to understand and hack on. :^) Some notable changes: - LayoutNode -> Layout::Node - LayoutBox -> Layout::Box - LayoutBlock -> Layout::BlockBox - LayoutReplaced -> Layout::ReplacedBox - LayoutDocument -> Layout::InitialContainingBlockBox - LayoutText -> Layout::TextNode - LayoutInline -> Layout::InlineNode Note that this is not strictly a "box tree" as we also hang inline/text nodes in the same tree, and they don't generate boxes. (Instead, they contribute line box fragments to their containing block!)
2020-11-22 15:53:01 +01:00
const DOM::Document& dom_node() const { return static_cast<const DOM::Document&>(*Node::dom_node()); }
LibHTML: Get rid of the style tree We now create a layout tree directly from the DOM tree. This way we don't actually lose text nodes ^)
2019-09-21 15:32:17 +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 paint_all_phases(PaintContext&);
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
LayoutRange const& selection() const { return m_selection; }
void set_selection(LayoutRange const&);
void set_selection_end(LayoutPosition const&);
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
LibWeb: Build stacking context tree lazily There's no actual need to build the stacking context tree before performing layout. Instead, make it lazy and build the tree when it's actually needed for something. This avoids a bunch of work in situations where multiple synchronous layouts are forced (typically by JavaScript) without painting or hit testing taking place in between. It also opens up for style invalidations that only target the stacking context tree.
2022-03-21 10:56:02 +01:00
void build_stacking_context_tree_if_needed();
LibWeb: Remember the selection state of each LayoutNode Instead of computing it on the fly while painting each layout node, they now remember their selection state. This avoids a whole bunch of tree traversal while painting with anything selected.
2020-08-21 17:50:41 +02:00
void recompute_selection_states();
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
private:
LibWeb: Build stacking context tree lazily There's no actual need to build the stacking context tree before performing layout. Instead, make it lazy and build the tree when it's actually needed for something. This avoids a bunch of work in situations where multiple synchronous layouts are forced (typically by JavaScript) without painting or hit testing taking place in between. It also opens up for style invalidations that only target the stacking context tree.
2022-03-21 10:56:02 +01:00
void build_stacking_context_tree();
LibWeb: Add fast_is<Layout::InitialContainingBlockBox> This is used by Layout::Node::containing_block() which is fairly hot.
2021-08-18 11:44:05 +02:00
virtual bool is_initial_containing_block_box() const override { return true; }
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
LayoutRange m_selection;
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
LibWeb: Add fast_is<Layout::InitialContainingBlockBox> This is used by Layout::Node::containing_block() which is fairly hot.
2021-08-18 11:44:05 +02:00
template<>
LibWeb: Rename InitialContainingBlockBox => InitialContainingBlock The "Box" suffix added nothing here.
2021-09-08 11:27:46 +02:00
inline bool Node::fast_is<InitialContainingBlock>() const { return is_initial_containing_block_box(); }
LibWeb: Add fast_is<Layout::InitialContainingBlockBox> This is used by Layout::Node::containing_block() which is fairly hot.
2021-08-18 11:44:05 +02:00
LibWeb: Respect CSS z-index property while painting To support z-ordering when painting, the layout tree now has a parallel sparse tree of stacking contexts. The rules for which layout boxes establish a stacking context are a bit complex, but the intent is to encapsulate the decision making into establishes_stacking_context(). When we paint, we start from the ICB (LayoutDocument) who always has a StackingContext and then paint the tree of StackingContexts where each node has its children sorted by z-index. This is pretty crude, but gets the basic job done. Note that this does not yet support hit testing; hit testing is still done using a naive treewalk from the root.
2020-06-15 17:29:35 +02:00
}
Reference in a new issue Copy permalink