Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/Layout/Viewport.h

40 lines
975 B
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 Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
* Copyright (c) 2018-2023, 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>
LibWeb: Use DOM Selection instead of ad-hoc layout tree selection Before this patch, we were expressing the current selection as a range between two points in the layout tree. This was a made-up concept I called LayoutRange (2x LayoutPosition) and as it turns out, we don't actually need it! Instead, we can just use the Selection API from the Selection API spec. This API expresses selection in terms of the DOM, and we already had many of the building blocks implemented. To ensure that selections get visually updated when the underlying Range of an active Selection is programmatically manipulated, Range now has an "associated Selection". If a range is updated while associated with a selection, we recompute layout tree selection states and repaint the page to make it user-visible.
2023-01-11 19:48:53 +01:00
#include <LibWeb/Selection/Selection.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::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
class Viewport final : public BlockContainer {
JS_CELL(Viewport, BlockContainer);
LibWeb: Make the layout tree GC-allocated This removes a set of complex reference cycles between DOM, layout tree and browsing context. It also makes lifetimes much easier to reason about, as the DOM and layout trees are now free to keep each other alive.
2022-10-17 14:41:50 +02:00
LibHTML: Start fleshing out a basic layout tree.
2019-06-15 22:49:44 +02:00
public:
LibWeb: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
explicit Viewport(DOM::Document&, NonnullRefPtr<CSS::StyleProperties>);
virtual ~Viewport() 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
LibWeb: Use DOM Selection instead of ad-hoc layout tree selection Before this patch, we were expressing the current selection as a range between two points in the layout tree. This was a made-up concept I called LayoutRange (2x LayoutPosition) and as it turns out, we don't actually need it! Instead, we can just use the Selection API from the Selection API spec. This API expresses selection in terms of the DOM, and we already had many of the building blocks implemented. To ensure that selections get visually updated when the underlying Range of an active Selection is programmatically manipulated, Range now has an "associated Selection". If a range is updated while associated with a selection, we recompute layout tree selection states and repaint the page to make it user-visible.
2023-01-11 19:48:53 +01:00
JS::GCPtr<Selection::Selection> selection() 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: Rename Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
virtual bool is_viewport() const override { return true; }
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 Layout::InitialContainingBlock to Layout::Viewport The name "initial containing block" was wrong for this, as it doesn't correspond to the HTML element, and that's specifically what it's supposed to do! :^)
2023-02-25 11:04:29 +01:00
inline bool Node::fast_is<Viewport>() const { return is_viewport(); }
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