dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/Layout/InlineNode.cpp

40 lines
1.3 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 05:38:21 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2018-2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Give InlineNodes a background This now uses the same code as Box, so images, repeat-rules, and anything that's added in the future will work for `display: inline` elements too. :^)
2021-09-19 13:16:00 -03:00
* Copyright (c) 2021, Sam Atkins <atkinssj@serenityos.org>
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 16:29:47 -03:00
* Copyright (c) 2024, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
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 05:38:21 -03: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 05:24:48 -03: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 05:38:21 -03:00
*/
LibWeb: Paint inspection outline for InlineNodes :^) This iterates the fragments of the containing block, and paints their outlines if they are descendants of the InlineNode. If multiple fragments are adjacent, eg: ```html <span><b>Well</b> hello <i>friends!</i></span> ``` ...then we get a double-thick outline between "Well", " hello " and "friends!", but we can come back to this after we implement non-rectangular outlines for the `outline` CSS property.
2021-08-19 08:20:43 -03:00
#include <LibWeb/DOM/Document.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 06:32:51 -03:00
#include <LibWeb/DOM/Element.h>
LibWeb: First slightly naive implementation of CSS floats :^) Boxes can now be floated left or right, which makes text within the same block formatting context flow around them. We were creating way too many block formatting contexts. As it turns out, we don't need one for every new block, but rather there's a set of rules that determines whether a given block creates a new block formatting context. Each BFC keeps track of the floating boxes within it, and IFC's can then query it to find the available space for line boxes. There's a huge hack in here where we assume all lines are the exact line-height. Making this work with vertically non-uniform lines will require some architectural changes.
2020-12-05 16:10:39 -03:00
#include <LibWeb/Layout/InlineFormattingContext.h>
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 11:53:01 -03:00
#include <LibWeb/Layout/InlineNode.h>
LibWeb: Split PaintableWithLines from PaintableBox No functional changes. I just hope to improve code navigation.
2026-01-08 13:17:32 -03:00
#include <LibWeb/Painting/PaintableWithLines.h>
LibHTML: Add stub classes for basic table layout This class introduces LayoutTable, LayoutTableRow and LayoutTableCell. These are produced by "display" values table, table-row and table-cell respectively. Note that there's no layout happening yet, I'm just adding the classes.
2019-10-17 18:09:41 -03: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 11:53:01 -03:00
namespace Web::Layout {
LibWeb: Move everything into the Web namespace
2020-03-07 06:27:02 -03:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC_DEFINE_ALLOCATOR(InlineNode);
LibWeb: Add calls to JS_{DECLARE,DEFINE}_ALLOCATOR()
2024-04-06 14:16:04 -03:00
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 12:35:12 -03:00
InlineNode::InlineNode(DOM::Document& document, DOM::Element* element, GC::Ref<CSS::ComputedProperties> style)
LibWeb: Make `display: foo` box constructors take the Element by pointer This means we can instantiate them for pseudo-elements, which don't have an associated Element. They all pass it to their parent as a `Layout::Node*` and handle a lack of `layout_node()` already so this won't affect any functionality.
2022-02-23 17:25:35 -03:00
: Layout::NodeWithStyleAndBoxModelMetrics(document, element, move(style))
LibHTML: Add stub classes for basic table layout This class introduces LayoutTable, LayoutTableRow and LayoutTableCell. These are produced by "display" values table, table-row and table-cell respectively. Note that there's no layout happening yet, I'm just adding the classes.
2019-10-17 18:09:41 -03:00
{
}
Libraries: Use default constructors/destructors in LibWeb https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 16:21:51 -03:00
InlineNode::~InlineNode() = default;
LibHTML: Add stub classes for basic table layout This class introduces LayoutTable, LayoutTableRow and LayoutTableCell. These are produced by "display" values table, table-row and table-cell respectively. Note that there's no layout happening yet, I'm just adding the classes.
2019-10-17 18:09:41 -03:00
LibWeb: Make Paintable tree ref-counted The Paintable tree and its supplemental painting data structures were GC allocated because that was the easiest way to manage it and avoid leaks introduced by ref cycles. This included the Paintable subclasses themselves plus StackingContext, ChromeWidget, Scrollbar, ResizeHandle, and scroll-frame state. We are now trying to reduce GC allocation churn on layout and painting updates, so keeping this short-lived rendering tree outside the JS heap is a better fit. Move Paintable to RefCountedTreeNode, make painting helpers ref-counted or weakly reference Paintables, and update the layout and event-handler call sites to use RefPtr/WeakPtr ownership.
2026-05-07 08:38:05 -03:00
NonnullRefPtr<Painting::PaintableWithLines> InlineNode::create_paintable_for_line_with_index(size_t line_index) const
LibWeb: Create "empty" line box fragments for inline elements In order for inline elements (e.g <span>) to contribute padding etc. to line boxes, we now create special "leading" and "trailing" fragments for Layout::InlineNode and size them according to the horizontal padding values. The height of these fragments is taken from the tallest fragment on the line. (Perhaps we should stop having per-fragment heights and just keep a single height per line box, but that's a separate issue.) In order to make things look nice, we now also adjust the height of all fragments on a line so that nobody is shorter than the CSS line-height.
2020-12-03 15:21:33 -03:00
{
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 16:29:47 -03:00
for (auto const& paintable : paintables()) {
LibWeb: Make Paintable tree ref-counted The Paintable tree and its supplemental painting data structures were GC allocated because that was the easiest way to manage it and avoid leaks introduced by ref cycles. This included the Paintable subclasses themselves plus StackingContext, ChromeWidget, Scrollbar, ResizeHandle, and scroll-frame state. We are now trying to reduce GC allocation churn on layout and painting updates, so keeping this short-lived rendering tree outside the JS heap is a better fit. Move Paintable to RefCountedTreeNode, make painting helpers ref-counted or weakly reference Paintables, and update the layout and event-handler call sites to use RefPtr/WeakPtr ownership.
2026-05-07 08:38:05 -03:00
if (is<Painting::PaintableWithLines>(*paintable)) {
auto const& paintable_with_lines = static_cast<Painting::PaintableWithLines const&>(*paintable);
LibWeb: Replace InlinePaintable with PaintableWithLines created per line InlinePaintable was an ad-hoc paintable type required to support the fragmentation of inline nodes across multiple lines. It existed because there was no way to associate multiple paintables with a single layout node. This resulted in a lot of duplicated code between PaintableBox and InlinePaintable. For example, most of the CSS properties like background, border, shadows, etc. and hit-testing are almost identical for both of them. However, the code had to be duplicated to account for the fact that InlinePaintable creates a box for each line. And we had quite many places that operate on paintables with a code like: ``` if (box.is_paintable_box()) { // do something } else (box.is_inline_paintable()) { // do exactly the same as for paintable box but using InlinePaintable } ``` This change replaces the usage of `InlinePaintable` with `PaintableWithLines` created for each line, which is now possible because we support having multiple paintables per layout node. By doing that, we remove lots of duplicated code and bring our implementation closer to the spec.
2024-10-13 16:29:47 -03:00
if (paintable_with_lines.line_index() == line_index) {
return const_cast<Painting::PaintableWithLines&>(paintable_with_lines);
}
}
}
return Painting::PaintableWithLines::create(*this, line_index);
LibWeb: Give InlineNodes a background This now uses the same code as Box, so images, repeat-rules, and anything that's added in the future will work for `display: inline` elements too. :^)
2021-09-19 13:16:00 -03:00
}
LibWeb: Move everything into the Web namespace
2020-03-07 06:27:02 -03:00
}
Reference in a new issue Copy permalink