Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-18 09:50:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/Layout/InlineLevelIterator.cpp

464 lines
19 KiB
C++
Raw Permalink Normal View History

LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2022, Andreas Kling <andreas@ladybird.org>
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWeb: Remove Document.h include from SVGElement.h This reduces the recompilation cascade when Document.h is modified, cutting off the transitive path through ~30 SVG element headers. Move the inline try_resolve_url_to() template body in SVGGraphicsElement.h to a non-template helper in the .cpp file to avoid needing Document.h and ShadowRoot.h in the header. Add explicit includes to files that relied on the transitive dependency.
2026-02-08 17:13:36 +01:00
#include <LibWeb/DOM/ShadowRoot.h>
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
#include <LibWeb/HTML/FormAssociatedElement.h>
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
#include <LibWeb/Layout/BreakNode.h>
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
#include <LibWeb/Layout/InlineFormattingContext.h>
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
#include <LibWeb/Layout/InlineLevelIterator.h>
#include <LibWeb/Layout/InlineNode.h>
LibWeb: Make InlineLevelIterator ignore list item marker boxes Marker boxes are managed explicitly by the corresponding list item box.
2022-01-20 16:17:29 +01:00
#include <LibWeb/Layout/ListItemMarkerBox.h>
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
#include <LibWeb/Layout/ReplacedBox.h>
namespace Web::Layout {
LibWeb: Use cached UsedValues pointer in IFC and its helper classes This avoids expensive LayoutState lookups when we already have the pointer sitting around anyway.
2024-03-15 19:25:00 +01:00
InlineLevelIterator::InlineLevelIterator(Layout::InlineFormattingContext& inline_formatting_context, Layout::LayoutState& layout_state, Layout::BlockContainer const& containing_block, LayoutState::UsedValues const& containing_block_used_values, LayoutMode layout_mode)
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
: m_inline_formatting_context(inline_formatting_context)
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
, m_layout_state(layout_state)
LibWeb: Use cached UsedValues pointer in IFC and its helper classes This avoids expensive LayoutState lookups when we already have the pointer sitting around anyway.
2024-03-15 19:25:00 +01:00
, m_containing_block(containing_block)
, m_containing_block_used_values(containing_block_used_values)
, m_next_node(containing_block.first_child())
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
, m_layout_mode(layout_mode)
{
skip_to_next();
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
generate_all_items();
}
void InlineLevelIterator::generate_all_items()
{
for (;;) {
auto item = generate_next_item();
if (!item.has_value())
break;
// Track accumulated width for tab calculations.
// Reset on forced breaks since tabs measure from line start.
if (item->type == Item::Type::ForcedBreak) {
m_accumulated_width_for_tabs = 0;
} else {
m_accumulated_width_for_tabs += item->border_box_width();
}
m_items.append(item.release_value());
}
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
}
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
void InlineLevelIterator::enter_node_with_box_model_metrics(Layout::NodeWithStyleAndBoxModelMetrics const& node)
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
{
if (!m_extra_leading_metrics.has_value())
m_extra_leading_metrics = ExtraBoxMetrics {};
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
// FIXME: It's really weird that *this* is where we assign box model metrics for these layout nodes..
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
auto& used_values = m_layout_state.get_mutable(node);
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
auto const& computed_values = node.computed_values();
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.margin_top = computed_values.margin().top().to_px_or_zero(node, m_containing_block_used_values.content_width());
used_values.margin_bottom = computed_values.margin().bottom().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Resolve used vertical margins on inline elements Even though we don't actually make use of these values at the moment, we still want them to be reflected correctly once we start exposing used margin values soon.
2025-02-22 14:59:09 +01:00
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.margin_left = computed_values.margin().left().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
used_values.border_left = computed_values.border_left().width;
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.padding_left = computed_values.padding().left().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.margin_right = computed_values.margin().right().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Resolve used vertical margins on inline elements Even though we don't actually make use of these values at the moment, we still want them to be reflected correctly once we start exposing used margin values soon.
2025-02-22 14:59:09 +01:00
used_values.border_right = computed_values.border_right().width;
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.padding_right = computed_values.padding().right().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Resolve used vertical margins on inline elements Even though we don't actually make use of these values at the moment, we still want them to be reflected correctly once we start exposing used margin values soon.
2025-02-22 14:59:09 +01:00
LibWeb: Resolve vertical borders for inline nodes Preparation for upcoming change where InlinePaintable will no longer be responsible for doing that.
2024-10-15 20:08:48 +02:00
used_values.border_top = computed_values.border_top().width;
used_values.border_bottom = computed_values.border_bottom().width;
LibWeb: Make LengthBox hold LengthPercentageOrAuto Not every user of this requires an `auto` state, but most do. This has quite a big diff but most of that is mechanical: LengthPercentageOrAuto has `resolved_or_auto()` instead of `resolved()`, and `to_px_or_zero()` instead of `to_px()`, to make their output clearer.
2025-09-01 12:51:52 +01:00
used_values.padding_bottom = computed_values.padding().bottom().to_px_or_zero(node, m_containing_block_used_values.content_width());
used_values.padding_top = computed_values.padding().top().to_px_or_zero(node, m_containing_block_used_values.content_width());
LibWeb: Resolve vertical padding of inline elements
2024-04-23 13:34:09 -06:00
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
m_extra_leading_metrics->margin += used_values.margin_left;
m_extra_leading_metrics->border += used_values.border_left;
m_extra_leading_metrics->padding += used_values.padding_left;
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
LibWeb: Resolve CSS inset properties when entering inline-flow elements We don't actually apply the insets anywhere yet, but at least now they are available in the node's layout state.
2023-08-15 09:34:06 +02:00
// Now's our chance to resolve the inset properties for this node.
LibWeb: Fix percentage insets resolution for grid items compute_inset() was incorrectly retrieving the containing block size because containing_block() is unaware of grid areas that form a containing block for grid items but do not exist in the layout tree. With this change, we explicitly pass the containing block into compute_inset(), allowing it to correctly provide the containing block sizes for grid items.
2024-11-11 15:54:21 +01:00
m_inline_formatting_context.compute_inset(node, m_inline_formatting_context.content_box_rect(m_containing_block_used_values).size());
LibWeb: Resolve CSS inset properties when entering inline-flow elements We don't actually apply the insets anywhere yet, but at least now they are available in the node's layout state.
2023-08-15 09:34:06 +02:00
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
m_box_model_node_stack.append(node);
}
void InlineLevelIterator::exit_node_with_box_model_metrics()
{
if (!m_extra_trailing_metrics.has_value())
m_extra_trailing_metrics = ExtraBoxMetrics {};
auto& node = m_box_model_node_stack.last();
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
auto& used_values = m_layout_state.get_mutable(node);
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
LibWeb: Rename LayoutState::NodeState => LayoutState::UsedValues This object contains all the CSS "used values" as seen during the layout process, so calling it "used values" seems appropriate. :^)
2022-07-16 23:43:48 +02:00
m_extra_trailing_metrics->margin += used_values.margin_right;
m_extra_trailing_metrics->border += used_values.border_right;
m_extra_trailing_metrics->padding += used_values.padding_right;
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
m_box_model_node_stack.take_last();
}
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
// This is similar to Layout::Node::next_in_pre_order() but will not descend into inline-block nodes.
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
Layout::Node const* InlineLevelIterator::next_inline_node_in_pre_order(Layout::Node const& current, Layout::Node const* stay_within)
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
{
LibWeb: Use CSS::Display::is_flow_inside() in InlineLevelIterator This is a more correct check than !is_inline_block(), as it now enters all elements that have inline behavior on the outside and flow behavior on the inside.
2022-10-06 16:21:11 +02:00
if (current.first_child()
&& current.first_child()->display().is_inline_outside()
&& current.display().is_flow_inside()
&& !current.is_replaced_box()) {
LibWeb: Support CSS floats in inline flow CSS floats are now emitted by the InlineLevelIterator. When this happens, IFC coordinates with the parent BFC to float the box to the side, using the current LineBuilder state for vertical placement. This makes the "instructions" text on Acid3 render as a single contiguous flow of inline content.
2022-03-22 19:18:05 +01:00
if (!current.is_box() || !static_cast<Box const&>(current).is_out_of_flow(m_inline_formatting_context))
return current.first_child();
}
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
Layout::Node const* node = &current;
Layout::Node const* next = nullptr;
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
while (!(next = node->next_sibling())) {
node = node->parent();
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
// If node is the last node on the "box model node stack", pop it off.
if (!m_box_model_node_stack.is_empty()
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
&& m_box_model_node_stack.last() == node) {
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
exit_node_with_box_model_metrics();
}
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
if (!node || node == stay_within)
return nullptr;
}
LibWeb: Fix InlineLevelIterator not exiting box model metric nodes We were neglecting to pop nodes from the box model stack. The metrics were already being zeroed out when used, but let's not grow the stack needlessly.
2022-02-26 09:25:24 +01:00
// If node is the last node on the "box model node stack", pop it off.
if (!m_box_model_node_stack.is_empty()
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
&& m_box_model_node_stack.last() == node) {
LibWeb: Fix InlineLevelIterator not exiting box model metric nodes We were neglecting to pop nodes from the box model stack. The metrics were already being zeroed out when used, but let's not grow the stack needlessly.
2022-02-26 09:25:24 +01:00
exit_node_with_box_model_metrics();
}
LibWeb: Teach InlineLevelIterator to skip across inline-block elements We don't want to descend into inline-block containers when iterating inline-level items, since that would make the inline-level children of the inline-block bubble up to the containing block of the inline-block.
2022-01-20 12:18:25 +01:00
return next;
}
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
void InlineLevelIterator::compute_next()
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
{
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
if (m_next_node == nullptr)
return;
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
do {
LibWeb: Use cached UsedValues pointer in IFC and its helper classes This avoids expensive LayoutState lookups when we already have the pointer sitting around anyway.
2024-03-15 19:25:00 +01:00
m_next_node = next_inline_node_in_pre_order(*m_next_node, m_containing_block);
LibWeb: Support masking of SVGForeignObjectPaintable
2024-04-25 21:10:30 +02:00
if (m_next_node && m_next_node->is_svg_mask_box()) {
// NOTE: It is possible to encounter SVGMaskBox nodes while doing layout of formatting context established by <foreignObject> with a mask.
// We should skip and let SVGFormattingContext take care of them.
m_next_node = m_next_node->next_sibling();
}
LibWeb: Support CSS floats in inline flow CSS floats are now emitted by the InlineLevelIterator. When this happens, IFC coordinates with the parent BFC to float the box to the side, using the current LineBuilder state for vertical placement. This makes the "instructions" text on Acid3 render as a single contiguous flow of inline content.
2022-03-22 19:18:05 +01:00
} while (m_next_node && (!m_next_node->is_inline() && !m_next_node->is_out_of_flow(m_inline_formatting_context)));
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
}
void InlineLevelIterator::skip_to_next()
{
LibWeb: Use CSS::Display::is_flow_inside() in InlineLevelIterator This is a more correct check than !is_inline_block(), as it now enters all elements that have inline behavior on the outside and flow behavior on the inside.
2022-10-06 16:21:11 +02:00
if (m_next_node
&& is<Layout::NodeWithStyleAndBoxModelMetrics>(*m_next_node)
&& m_next_node->display().is_flow_inside()
&& !m_next_node->is_out_of_flow(m_inline_formatting_context)
&& !m_next_node->is_replaced_box())
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
enter_node_with_box_model_metrics(static_cast<Layout::NodeWithStyleAndBoxModelMetrics const&>(*m_next_node));
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
m_current_node = m_next_node;
compute_next();
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
}
LibWeb: Remove unused argument of InlineLevelIterator::next Also remove unused method from LineBuilder.
2023-08-17 05:38:52 +00:00
Optional<InlineLevelIterator::Item> InlineLevelIterator::next()
LibWeb: Improve the line breaking algorithm Check the width of the next token after white space to decide line breaks. The next width can also be the total width of multiple tokens. This better follows the CSS Text specification and matches behavior of other browsers. Fixes #20388.
2023-08-19 03:36:53 +00:00
{
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
if (m_next_item_index >= m_items.size())
return {};
return m_items[m_next_item_index++];
LibWeb: Improve the line breaking algorithm Check the width of the next token after white space to decide line breaks. The next width can also be the total width of multiple tokens. This better follows the CSS Text specification and matches behavior of other browsers. Fixes #20388.
2023-08-19 03:36:53 +00:00
}
CSSPixels InlineLevelIterator::next_non_whitespace_sequence_width()
{
CSSPixels next_width = 0;
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
for (size_t i = m_next_item_index; i < m_items.size(); ++i) {
auto const& next_item = m_items[i];
LibWeb: Stop collecting lookahead items on forced break This avoids a crash since such items don't have a node nor CSS properties. Fixes crashes on Wikipedia pages which contain preformatted code.
2023-08-22 06:38:17 +00:00
if (next_item.type == InlineLevelIterator::Item::Type::ForcedBreak)
break;
LibWeb: Convert `white-space` CSS property to shorthand This exposed a few bugs which caused the following tests to behave incorrectly: - `tab-size-text-wrap.html`: This previously relied on a bug where we incorrectly treated `white-space: pre` as allowing text wrapping. The fix here is to implement the text-wrap CSS shorthand property. - `execCommand-preserveWhitespace.html`: We don't correctly serialize shorthand properties. This is covered by an existing FIXME in `CSSStyleProperties::serialized()` - `white-space-shorthand.html`: The last 5 subtests here fail as we don't correctly handle shorthand properties in `CSSStyleProperties::remove_property()`. This is covered by an existing FIXME in said function.
2025-05-22 00:31:24 +12:00
if (next_item.node->computed_values().text_wrap_mode() == CSS::TextWrapMode::Wrap) {
LibWeb: Improve the line breaking algorithm Check the width of the next token after white space to decide line breaks. The next width can also be the total width of multiple tokens. This better follows the CSS Text specification and matches behavior of other browsers. Fixes #20388.
2023-08-19 03:36:53 +00:00
if (next_item.type != InlineLevelIterator::Item::Type::Text)
break;
if (next_item.is_collapsible_whitespace)
break;
LibWeb: Add `const` where possible in InlineLevelIterator
2025-08-08 21:13:35 +10:00
auto const& next_text_node = as<Layout::TextNode>(*(next_item.node));
LibWeb: Port rendered text to UTF-16 This migrates TextNode::text_for_rendering() to Utf16String and deals with the fallout. As a consequence, this effectively reverts commit 3df83dade80ad0dbcd27a8f6a6f1b540ff58c8f2. The layout test expecation file updates are because we now express text lengths and offsets in UTF-16 code units. The selection-over-multiple-code-units expectation file update actually represents a correctness fix. Our result now matches Firefox.
2025-07-25 09:34:41 -04:00
auto next_view = next_text_node.text_for_rendering().substring_view(next_item.offset_in_node, next_item.length_in_node);
if (next_view.is_ascii_whitespace())
LibWeb: Improve the line breaking algorithm Check the width of the next token after white space to decide line breaks. The next width can also be the total width of multiple tokens. This better follows the CSS Text specification and matches behavior of other browsers. Fixes #20388.
2023-08-19 03:36:53 +00:00
break;
}
next_width += next_item.border_box_width();
}
return next_width;
}
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
Gfx::GlyphRun::TextType InlineLevelIterator::resolve_text_direction_from_context()
{
VERIFY(m_text_node_context.has_value());
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
// Search forward in the pre-generated chunks array to find the next chunk with known direction.
// Since chunks are pre-generated, this is just O(1) array access per iteration.
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
Optional<Gfx::GlyphRun::TextType> next_known_direction;
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
for (size_t i = m_text_node_context->next_chunk_index; i < m_text_node_context->chunks.size(); ++i) {
auto const& chunk = m_text_node_context->chunks[i];
if (chunk.text_type == Gfx::GlyphRun::TextType::Ltr || chunk.text_type == Gfx::GlyphRun::TextType::Rtl) {
next_known_direction = chunk.text_type;
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
break;
}
}
auto last_known_direction = m_text_node_context->last_known_direction;
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
if (last_known_direction.has_value() && next_known_direction.has_value() && *last_known_direction != *next_known_direction) {
switch (m_containing_block->computed_values().direction()) {
case CSS::Direction::Ltr:
return Gfx::GlyphRun::TextType::Ltr;
case CSS::Direction::Rtl:
return Gfx::GlyphRun::TextType::Rtl;
}
}
if (last_known_direction.has_value())
return *last_known_direction;
if (next_known_direction.has_value())
return *next_known_direction;
return Gfx::GlyphRun::TextType::ContextDependent;
}
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
Optional<InlineLevelIterator::Item> InlineLevelIterator::generate_next_item()
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
{
if (!m_current_node)
return {};
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
if (auto* text_node = as_if<Layout::TextNode>(*m_current_node)) {
LibWeb: Make whitespace collapsing stateless Previously, the whitespace collapsing code had a parameter telling it whether the previous text node ended in whitespace. This was not actually necessary, so let's get rid of it.
2022-03-27 21:14:10 +02:00
if (!m_text_node_context.has_value())
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
enter_text_node(*text_node);
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
// Track chunk position locally
bool is_first_chunk = (m_text_node_context->next_chunk_index == 0);
// Get the next chunk from the pre-generated array
Optional<TextNode::Chunk> chunk_opt;
if (m_text_node_context->next_chunk_index < m_text_node_context->chunks.size()) {
chunk_opt = m_text_node_context->chunks[m_text_node_context->next_chunk_index++];
}
LibWeb: Peek after extracting next chunk in InlineLevelIterator Peek is used to determine if the current chunk is the last and if so, add trailing box metrics. For this to work correctly, it must be done only after calling next(), otherwise peek gives us the current chunk.
2025-10-18 13:56:50 +05:30
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
bool is_last_chunk = (m_text_node_context->next_chunk_index >= m_text_node_context->chunks.size());
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
auto is_empty_editable = false;
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
if (!chunk_opt.has_value()) {
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
auto const is_only_chunk = is_first_chunk && is_last_chunk;
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
if (is_only_chunk && text_node->text_for_rendering().is_empty()) {
if (auto const* shadow_root = as_if<DOM::ShadowRoot>(text_node->dom_node().root()))
if (auto const* form_associated_element = as_if<HTML::FormAssociatedTextControlElement>(shadow_root->host()))
LibWeb: Make every HTMLElement potentially form-associated This can be the case for form-associated custom elements, where any HTML element can be form-associated.
2026-02-15 03:14:09 +00:00
is_empty_editable = form_associated_element->text_control_to_html_element().is_mutable();
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
is_empty_editable |= text_node->dom_node().parent() && text_node->dom_node().parent()->is_editing_host();
}
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
if (is_empty_editable) {
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
// Create an empty chunk for editable empty text fields
chunk_opt = TextNode::Chunk {
.view = {},
.font = text_node->computed_values().font_list().first(),
.is_all_whitespace = true,
.text_type = Gfx::GlyphRun::TextType::Common,
};
// Advance the index so the next call will move to the next node
m_text_node_context->next_chunk_index = 1;
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
} else {
m_text_node_context = {};
LibWeb: Implement `word-break` functionality using UAX#14 line breaking We now use ICU's line break iterator to determine soft wrap opportunities, enabling correct line breaking for CJK text.
2026-01-20 09:23:51 +00:00
m_previous_chunk_can_break_after = false;
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
skip_to_next();
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
return generate_next_item();
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
}
}
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
auto& chunk = chunk_opt.value();
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
auto text_type = chunk.text_type;
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
if (text_type == Gfx::GlyphRun::TextType::Ltr || text_type == Gfx::GlyphRun::TextType::Rtl) {
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
m_text_node_context->last_known_direction = text_type;
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
}
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
auto do_respect_linebreak = m_text_node_context->should_respect_linebreaks;
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
if (do_respect_linebreak && chunk.has_breaking_newline) {
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
is_last_chunk = true;
LibWeb: Layout text chunks based on their Unicode direction Append text chunks to either the start or end of the text fragment, depending on the text direction. The direction is determined by what script its code points are from.
2024-08-18 17:58:05 +01:00
if (chunk.is_all_whitespace)
text_type = Gfx::GlyphRun::TextType::EndPadding;
}
if (text_type == Gfx::GlyphRun::TextType::ContextDependent)
text_type = resolve_text_direction_from_context();
LibWeb: Make text newlines in "pre" mode emit a ForcedBreak item Instead of emitting a Text item with the "should_force_break" flag set to true, newlines in newline-preserving text content now timply turn into ForcedBreak items. This makes the <pre> element work again.
2022-03-26 18:59:54 +01:00
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
if (do_respect_linebreak && chunk.has_breaking_newline)
return Item { .type = Item::Type::ForcedBreak };
LibWeb: Make text newlines in "pre" mode emit a ForcedBreak item Instead of emitting a Text item with the "should_force_break" flag set to true, newlines in newline-preserving text content now timply turn into ForcedBreak items. This makes the <pre> element work again.
2022-03-26 18:59:54 +01:00
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
auto letter_spacing = text_node->computed_values().letter_spacing();
LibWeb: Support percentages in `word-spacing` Fixes crash in the created test as well as https://wpt.live/css/css-text /word-spacing/reference/word-spacing-percent-001-ref.html. The WPT test hasn't been imported as it passing is currently a false-positive due to the fact that we don't yet respect `word-spacing` in most cases.
2025-08-02 00:07:48 +12:00
// FIXME: We should apply word spacing to all word-separator characters not just breaking tabs
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
auto word_spacing = text_node->computed_values().word_spacing();
LibWeb: Start implementing letter spacing Letter spacing is applied during text shaping and `shape_text` is used in places other `InlineLevelIterator` so way may have more work to do, however this is a good start :^).
2024-11-05 07:11:34 +00:00
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
auto x = 0.0f;
if (chunk.has_breaking_tab) {
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
// Use the accumulated width we've been tracking during pre-generation.
// This accounts for items that would appear before this tab on the same line.
CSSPixels accumulated_width = m_accumulated_width_for_tabs;
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
// https://drafts.csswg.org/css-text/#tab-size-property
LibWeb: Resolve more calculated values in ComputedProperties We simplify these at style computation time so there is no need to maintain them as {Number|Length}OrCalculated Reduces the time spent in `Length::ResolutionContext::for_layout_node` from 3.3% to 0.4% when loading https://en.wikipedia.org/wiki/2023_in_American_television
2025-11-09 16:28:32 +13:00
auto tab_width = text_node->computed_values().tab_size().visit(
[&](CSS::Length const& length) -> CSSPixels {
return length.absolute_length_to_px();
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
},
LibWeb: Resolve more calculated values in ComputedProperties We simplify these at style computation time so there is no need to maintain them as {Number|Length}OrCalculated Reduces the time spent in `Length::ResolutionContext::for_layout_node` from 3.3% to 0.4% when loading https://en.wikipedia.org/wiki/2023_in_American_television
2025-11-09 16:28:32 +13:00
[&](double tab_number) -> CSSPixels {
LibWeb: Bring tab-size closer to the spec When the css tab-size property is a number, we need to add the associated letter-spacing and word-spacing to it's width.
2024-10-23 08:27:22 +01:00
return CSSPixels::nearest_value_for(tab_number * (chunk.font->glyph_width(' ') + word_spacing.to_float() + letter_spacing.to_float()));
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
});
// https://drafts.csswg.org/css-text/#white-space-phase-2
// if fragments have added to the width, calculate the net distance to the next tab stop, otherwise the shift will just be the tab width
auto tab_stop_dist = accumulated_width > 0 ? (ceil((accumulated_width / tab_width)) * tab_width) - accumulated_width : tab_width;
auto ch_width = chunk.font->glyph_width('0');
// If this distance is less than 0.5ch, then the subsequent tab stop is used instead
if (tab_stop_dist < ch_width * 0.5)
tab_stop_dist += tab_width;
// account for consecutive tabs
auto num_of_tabs = 0;
for (auto code_point : chunk.view) {
if (code_point != '\t')
break;
num_of_tabs++;
}
tab_stop_dist = tab_stop_dist * num_of_tabs;
LibWeb: Strip tabs before text shaping Handling tabs during text shaping caused issues because we tried to index 'input_glyph_info' whilst iterating until 'glyph_count' and these can be different sizes. The difference is due to when one or more characters get merged into the same glyph when calling 'input_glyph_info' (see https://lazka.github.io/pgi-docs/HarfBuzz-0.0/classes/glyph_info_t.html). We don't want to render tabs as they come up as tofu characters so instead let's strip them out of the text chunk before starting text shaping.
2024-10-22 13:07:26 +01:00
// remove tabs, we don't want to render them when we shape the text
chunk.view = chunk.view.substring_view(num_of_tabs);
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
x = tab_stop_dist.to_float();
}
LibGfx+LibWeb: Resolve font features per font rather than per element Previously we would resolve font features (https://drafts.csswg.org/css-fonts-4/#feature-variation-precedence) per element, while this works for the current subset of the font feature resolution algorithm that we support, some as yet unimplemented parts require us to know whether we are resolving against a CSS @font-face rule, and if so which one (e.g. applying descriptors from the @font-face rule, deciding which @font-feature-values rules to apply, etc). To achieve this we store the data required to resolve font features in a struct and pass that to `FontComputer` which resolves the font features and stores them with the computed `Font`. We no longer need to invalidate the font shaping cache when features change since the features are defined per font (and therefore won't ever change).
2026-01-18 16:16:17 +13:00
auto glyph_run = Gfx::shape_text({ x, 0 }, letter_spacing.to_float(), chunk.view, chunk.font, text_type);
LibWeb: Start implementation of rendering tabs according to tab-size
2024-10-15 18:21:49 +01:00
LibGfx+LibWeb: Don't include start.x in GlyphRun width For some reason we were including x offset of start position into glyph run width. This is not correct and would be revealed by the upcoming changes.
2025-04-19 23:36:03 +02:00
CSSPixels chunk_width = CSSPixels::nearest_value_for(glyph_run->width() + x);
LibWeb: Don't add an extra glyph spacing to width of TextNode When calculating the width of text using a bitmap font, a glyph spacing is added at the end of each fragment, including the last one. This meant that everything was 1 pixel too long. This bug did not affect vector fonts.
2023-10-28 15:39:57 +02:00
LibWeb: Don't treat `content: ""` as collapsible whitespace I couldn't find anything in specs about this, but it seems to be roughly consistent with other engines.
2022-10-14 12:30:44 +02:00
// NOTE: We never consider `content: ""` to be collapsible whitespace.
LibWeb/Tests: Add empty text chunk in empty editables Otherwise the cursor won't get rendered in empty input fields.
2025-08-08 21:17:33 +10:00
bool is_generated_empty_string = is_empty_editable || (text_node->is_generated_for_pseudo_element() && chunk.length == 0);
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
auto collapse_whitespace = m_text_node_context->should_collapse_whitespace;
LibWeb: Don't treat `content: ""` as collapsible whitespace I couldn't find anything in specs about this, but it seems to be roughly consistent with other engines.
2022-10-14 12:30:44 +02:00
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
Item item {
.type = Item::Type::Text,
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
.node = text_node,
LibGfx+LibWeb: Simplify text shaping API by removing per glyph callback All places where text shaping happens, the callback is used to simply append a glyph into the end of glyphs vector. This change removes the callback parameter and makes the text shaping function return a glyph run.
2024-09-14 19:54:41 +02:00
.glyph_run = move(glyph_run),
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
.offset_in_node = chunk.start,
.length_in_node = chunk.length,
.width = chunk_width,
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
.is_collapsible_whitespace = collapse_whitespace && chunk.is_all_whitespace && !is_generated_empty_string,
LibWeb: Implement `word-break` functionality using UAX#14 line breaking We now use ICU's line break iterator to determine soft wrap opportunities, enabling correct line breaking for CJK text.
2026-01-20 09:23:51 +00:00
.can_break_before = m_previous_chunk_can_break_after,
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
};
LibWeb: Implement `word-break` functionality using UAX#14 line breaking We now use ICU's line break iterator to determine soft wrap opportunities, enabling correct line breaking for CJK text.
2026-01-20 09:23:51 +00:00
m_previous_chunk_can_break_after = chunk.can_break_after;
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
add_extra_box_model_metrics_to_item(item, is_first_chunk, is_last_chunk);
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
return item;
}
LibWeb: Don't skip position:relative elements in inline-level layout InlineLevelIterator was wrongly skipping over all positioned elements, instead of just the absolutely positioned ones.
2022-03-02 14:53:39 +01:00
if (m_current_node->is_absolutely_positioned()) {
LibWeb: Add `const` where possible in InlineLevelIterator
2025-08-08 21:13:35 +10:00
auto const& node = *m_current_node;
LibWeb: Make InlineLevelIterator skip over positioned elements
2022-02-15 01:54:22 +01:00
skip_to_next();
LibWeb: Make InlineLevelIterator emit absolutely positioned items Note that we don't put absolutely positioned items on a line! This is just so that IFC can discover boxes and pass them along to BFC. This fixes an issue where only direct children of the IFC containing block were considered for absolute positioning. Now we pick up absolutely positioned children of nested inline nodes as well.
2022-03-07 22:27:09 +01:00
return Item {
.type = Item::Type::AbsolutelyPositionedElement,
.node = &node,
};
LibWeb: Make InlineLevelIterator skip over positioned elements
2022-02-15 01:54:22 +01:00
}
LibWeb: Support CSS floats in inline flow CSS floats are now emitted by the InlineLevelIterator. When this happens, IFC coordinates with the parent BFC to float the box to the side, using the current LineBuilder state for vertical placement. This makes the "instructions" text on Acid3 render as a single contiguous flow of inline content.
2022-03-22 19:18:05 +01:00
if (m_current_node->is_floating()) {
LibWeb: Add `const` where possible in InlineLevelIterator
2025-08-08 21:13:35 +10:00
auto const& node = *m_current_node;
LibWeb: Support CSS floats in inline flow CSS floats are now emitted by the InlineLevelIterator. When this happens, IFC coordinates with the parent BFC to float the box to the side, using the current LineBuilder state for vertical placement. This makes the "instructions" text on Acid3 render as a single contiguous flow of inline content.
2022-03-22 19:18:05 +01:00
skip_to_next();
return Item {
.type = Item::Type::FloatingElement,
.node = &node,
};
}
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
if (is<Layout::BreakNode>(*m_current_node)) {
LibWeb: Add `const` where possible in InlineLevelIterator
2025-08-08 21:13:35 +10:00
auto const& node = *m_current_node;
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
skip_to_next();
return Item {
.type = Item::Type::ForcedBreak,
LibWeb: Handle float clearing specified on line break elements
2023-07-19 23:44:40 +00:00
.node = &node,
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
};
}
LibWeb: Make InlineLevelIterator ignore list item marker boxes Marker boxes are managed explicitly by the corresponding list item box.
2022-01-20 16:17:29 +01:00
if (is<Layout::ListItemMarkerBox>(*m_current_node)) {
skip_to_next();
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
return generate_next_item();
LibWeb: Make InlineLevelIterator ignore list item marker boxes Marker boxes are managed explicitly by the corresponding list item box.
2022-01-20 16:17:29 +01:00
}
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
if (!is<Layout::Box>(*m_current_node)) {
skip_to_next();
LibWeb: Pre-generate items in InlineLevelIterator Instead of generating items lazily during iteration (and using a lookahead queue for peeking), we now pre-generate all items upfront in the constructor. This allows next() and next_non_whitespace_sequence_width() to be simple O(1) array accesses instead of doing generation work. To handle tabs correctly (which need to know the accumulated width of content before them on the line), we track m_accumulated_width_for_tabs during pre-generation and reset it on forced breaks.
2026-01-10 13:22:55 +01:00
return generate_next_item();
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
}
LibWeb: Add `const` where possible in InlineLevelIterator
2025-08-08 21:13:35 +10:00
auto const& box = as<Layout::Box>(*m_current_node);
auto const& box_state = m_layout_state.get(box);
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
m_inline_formatting_context.dimension_box_on_line(box, m_layout_mode);
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
auto item = Item {
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
.type = Item::Type::Element,
.node = &box,
.offset_in_node = 0,
.length_in_node = 0,
LibWeb: Add accessors for UsedValues::computed_{width,height} This is preparation for doing some more work when assigning to these values.
2022-07-17 17:59:02 +02:00
.width = box_state.content_width(),
LibWeb: Start making our layout system "transactional" This patch adds a map of Layout::Node to FormattingState::NodeState. Instead of updating layout nodes incrementally as layout progresses through the formatting contexts, all updates are now written to the corresponding NodeState instead. At the end of layout, FormattingState::commit() is called, which transfers all the values from the NodeState objects to the Node. This will soon allow us to perform completely non-destructive layouts which don't affect the tree. Note that there are many imperfections here, and still many places where we assign to the NodeState, but later read directly from the Node instead. I'm just committing at this stage to make subsequent diffs easier to understand.
2022-02-20 15:51:24 +01:00
.padding_start = box_state.padding_left,
.padding_end = box_state.padding_right,
.border_start = box_state.border_left,
.border_end = box_state.border_right,
.margin_start = box_state.margin_left,
.margin_end = box_state.margin_right,
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
};
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
add_extra_box_model_metrics_to_item(item, true, true);
LibWeb: Prevent time-traveling leading inline metrics In `InlineLevelIterator`, whenever we call `skip_to_next()` and enter a node with box model metrics, we could potentially accumulate leading and trailing metrics. This lead to a weird situation where an element with `display: inline-block` could adopt the leading metrics of an inline element that follows it, since we perform the call to `add_extra_box_model_metrics_to_item()` too late. Move `skip_to_next()` down so it no longer interferes with the `Item` we're creating. The test expectation for `atomic-inline-with-percentage-vertical-align.html` is updated, although neither the old nor new results are 100% accurate since either box jumps one pixel to the right.
2025-06-20 00:40:15 +02:00
skip_to_next();
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
return item;
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
}
LibWeb: Make whitespace collapsing stateless Previously, the whitespace collapsing code had a parameter telling it whether the previous text node ended in whitespace. This was not actually necessary, so let's get rid of it.
2022-03-27 21:14:10 +02:00
void InlineLevelIterator::enter_text_node(Layout::TextNode const& text_node)
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
{
LibWeb: Convert `white-space` CSS property to shorthand This exposed a few bugs which caused the following tests to behave incorrectly: - `tab-size-text-wrap.html`: This previously relied on a bug where we incorrectly treated `white-space: pre` as allowing text wrapping. The fix here is to implement the text-wrap CSS shorthand property. - `execCommand-preserveWhitespace.html`: We don't correctly serialize shorthand properties. This is covered by an existing FIXME in `CSSStyleProperties::serialized()` - `white-space-shorthand.html`: The last 5 subtests here fail as we don't correctly handle shorthand properties in `CSSStyleProperties::remove_property()`. This is covered by an existing FIXME in said function.
2025-05-22 00:31:24 +12:00
auto white_space_collapse = text_node.computed_values().white_space_collapse();
auto text_wrap_mode = text_node.computed_values().text_wrap_mode();
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
// https://drafts.csswg.org/css-text-4/#collapse
LibWeb: Convert `white-space` CSS property to shorthand This exposed a few bugs which caused the following tests to behave incorrectly: - `tab-size-text-wrap.html`: This previously relied on a bug where we incorrectly treated `white-space: pre` as allowing text wrapping. The fix here is to implement the text-wrap CSS shorthand property. - `execCommand-preserveWhitespace.html`: We don't correctly serialize shorthand properties. This is covered by an existing FIXME in `CSSStyleProperties::serialized()` - `white-space-shorthand.html`: The last 5 subtests here fail as we don't correctly handle shorthand properties in `CSSStyleProperties::remove_property()`. This is covered by an existing FIXME in said function.
2025-05-22 00:31:24 +12:00
bool do_wrap_lines = text_wrap_mode == CSS::TextWrapMode::Wrap;
LibWeb: Store correct text offsets in PaintableFragment Previously, we were collapsing whitespace in Layout::TextNode and then passed the resulting string for further processing through ChunkIterator -> InlineLevelIterator -> InlineFormattingContext -> LineBuilder -> LineBoxFragment -> PaintableFragment. Our painting tree is where we deal with things like range offsets into the underlying text nodes, but since we modified the original string, the offsets were wrong. This changes the way we generate fragments: * Layout::TextNode no longer collapses whitespace as part of its stored "text for rendering", but moves this logic to ChunkIterator which splits up this text into separate views whenever whitespace needs to be collapsed. * Layout::LineBox now only extends the last fragment if its end offset is equal to the new fragment's start offset. Otherwise, there's a gap caused by collapsing whitespace and we need to generate a separate fragment for that in order to have a correct start offset. Some tests need new baselines because of the fixed start offsets. Fixes #566.
2025-09-12 10:06:27 +02:00
bool do_respect_linebreaks = first_is_one_of(white_space_collapse, CSS::WhiteSpaceCollapse::Preserve, CSS::WhiteSpaceCollapse::PreserveBreaks, CSS::WhiteSpaceCollapse::BreakSpaces);
LibWeb: Don't collapse TextNode if it's editable Fixes #16127
2022-11-26 00:14:36 +01:00
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
// Pre-generate all chunks for this text node upfront.
// This allows O(1) peek() and next() operations instead of lazy generation with O(n) queue operations.
TextNode::ChunkIterator chunk_iterator { text_node, do_wrap_lines, do_respect_linebreaks };
Vector<TextNode::Chunk> chunks;
while (true) {
auto chunk = chunk_iterator.next();
if (!chunk.has_value())
break;
chunks.append(chunk.release_value());
}
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
m_text_node_context = TextNodeContext {
LibWeb: Pre-generate text chunks in InlineLevelIterator Instead of lazily generating text chunks via ChunkIterator with a peek queue that used O(n) take_first() operations, we now pre-generate all chunks upfront when entering a text node. This makes chunk access O(1) via simple array indexing, which speeds up both next() calls and forward lookups for bidi direction resolution.
2026-01-10 12:03:54 +01:00
.chunks = move(chunks),
.next_chunk_index = 0,
.should_collapse_whitespace = chunk_iterator.should_collapse_whitespace(),
.should_wrap_lines = do_wrap_lines,
.should_respect_linebreaks = do_respect_linebreaks,
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
};
LibWeb: Support inline-level padding and border properly Here's roughly how this works: - InlineLevelIterator keeps a nesting stack of inline-level nodes with box model metrics. - When entering a node with box model metrics, we add them to the current "leading metrics". - When exiting a node with box model metrics, we add them to the current "trailing metrics". - Pending leading metrics are consumed by the first fragment added to the line. - Pending trailing metrics are consumed by the last fragment added to the line. Like before, the position of a line box fragment is the top left of its content box. However, fragments are placed horizontally along the line with space inserted for padding and border. InlineNode::paint() now expands the content rect as appropriate when painting background and borders. Note that margins and margin collapsing is not yet implemented. This makes the eyes on ACID2 horizontally centered. :^)
2022-02-14 15:52:29 +01:00
}
void InlineLevelIterator::add_extra_box_model_metrics_to_item(Item& item, bool add_leading_metrics, bool add_trailing_metrics)
{
if (add_leading_metrics && m_extra_leading_metrics.has_value()) {
item.margin_start += m_extra_leading_metrics->margin;
item.border_start += m_extra_leading_metrics->border;
item.padding_start += m_extra_leading_metrics->padding;
m_extra_leading_metrics = {};
}
if (add_trailing_metrics && m_extra_trailing_metrics.has_value()) {
item.margin_end += m_extra_trailing_metrics->margin;
item.border_end += m_extra_trailing_metrics->border;
item.padding_end += m_extra_trailing_metrics->padding;
m_extra_trailing_metrics = {};
}
LibWeb: Add inline-level iterator that enumerates items for line layout This patch adds a new mechanism that allows InlineFormattingContext to build line boxes incrementally instead of all-in-one go. Incremental build will eventually allow much better support for CSS floating objects.
2022-01-17 15:07:19 +01:00
}
}
Reference in a new issue Copy permalink