It's possible to resolve box's height without doing inner layout, when
computed value is not auto. Doing that fixes height resolution, when box
with percentage height has containing block with percentage height.
Before:
- resolve used width
- layout box's content
- resolve height
After:
- resolve used width
- resolve height if treated as not auto
- layout box's content
- resolve height if treated as auto
This mainly uses forward declarations as appropriate for input element
related files. This reduces the number of targets being built when we
change HTMLInputElement.h from 430 to 44.
The expensive part of creating a segmenter is doing the locale and UCD
data lookups at creation time. Instead of doing this once per text node,
cache the segmenters on the document, and clone them as needed (cloning
is much, much cheaper).
On a profile loading Ladybird's GitHub repo, the following hot methods
changed as follows:
ChunkIterator ctor: 6.08% -> 0.21%
Segmenter factory: 5.86% -> 0%
Segmenter clone: N/A -> 0.09%
..and delay static position calculation in IFC until trailing
whitespace are removed, because otherwise it's not possible to correctly
calculate x offset.
Containing block for abspos grid items depends on their grid placement:
- if element has definite grid position, then corresponding grid area
should be used as a containing block
- if element does not have definite grid position, then padding edge of
grid container should be used as a containing block
So offset should be adjusted for paddings only for boxes without
definite grid position.
Our current text iterator is not aware of multi-code point graphemes.
Instead of simply incrementing an iterator one code point at a time, use
our Unicode grapheme segmenter to break text into fragments.
When a block container has `clear` set and some clearance is applied,
that clearance prevents margins from adjoining and therefore resets
the margin state. But when a floating box has `clear` set, that
clearance only goes between floating boxes so should not reset margin
state. BlockFormattingContexts already do that correctly, and this PR
changes InlineFormattingContext to do the same.
Fixes#1462; adds reduced input from that issue as test.
...because calculate_inner_width() assumes layout state has resolved
paddings that could be used to account for "box-sizing: border-box".
Fixes regression introduced in 5f74da6ae8
Before this change, each BFC child that established an FC root was laid
out at least twice: the first time to perform a normal layout, and the
second time to perform an intrinsic layout to determine the automatic
content height. With this change, we avoid the second run by querying
the formatting context for the height it used after performing the
normal layout.
The `calculate_inner_width()` and `calculate_inner_height()` resolve
percentage paddings using the width returned by
`containing_block_width_for()`. However, this function does not account
for grids where the containing block is defined by the grid area to
which an item belongs.
This change fixes the issue by modifying `calculate_inner_width()` and
`calculate_inner_height()` to use the already resolved paddings from the
layout state. Corresponding changes ensure that paddings are resolved
and saved in the state before box-sizing is handled.
As a side effect, this change also improves abspos layout for BFC where
now paddings are resolved using padding box of containing block instead
of content box of containing block.
Fixes yet another case of GFC bug, where Node::containing_block() should
not be used for grid items, because their containing block is grid area
which is not represented in layout tree.
Although the parameter is named "available size," it is always supposed
to represent the containing block size whenever it has a definite value.
Therefore, it is possible to simply use this value instead of performing
a containing block lookup.
This change actually improves correctness for grid items whose
containing block is defined by the grid area, as
`Node::containing_block()` does not account for this.
Our abspos layout code assumes that available space is containing block
size, so this change aligns us with the spec by using grid area for this
value.
This change does not have attached test because it is required for
upcoming fix in calculate_inner_height() that will reveal the problem.
compute_width() could never be invoked for abspos boxes because they
are skipped during normal layout and processed in
parent_context_did_dimension_child_root_box()
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.
Use this cached pointer to the containing block's used values when
obviously possible. This avoids a hash lookup each time, and these
hash lookups do show up in profiles.
Change try_compute_width() to check whether min-width/max-width or width
is auto instead of always using `computed_values.width()`.
`grid/min-max-content.html` test is affected but it's progression.
Before this change, a formatting context was responsible for layout of
absolutely positioned boxes whose FC root box was their parent (either
directly or indirectly). This only worked correctly when the containing
block of the absolutely positioned child did not escape the FC root.
This is because the width and height of an absolutely positioned box are
resolved based on the size of its containing block, so we needed to
ensure that the containing block's layout was completed before laying
out an absolutely positioned box.
With this change, the layout of absolutely positioned boxes is delayed
until the FC responsible for the containing block's layout is complete.
This has affected the way we calculate the static position. It is no
longer possible to ask the FC for a box's static position, as this FC's
state might be gone by the time the layout for absolutely positioned
elements occurs. Instead, the "static position rectangle" (a concept
from the spec) is saved in the layout state, along with information on
how to align the box within this rectangle when its width and height are
resolved.
Absolutely positioned boxes do not affect the size of the formatting
context box they belong to, so it's safe to skip their layout entirely
when calculating intrinsic size.
FormattingContext::run() does not allow reentrancy, so it's safe to
save and access layout mode from FC object. This avoids need to drill it
through methods of a formatting context and makes it clear that this
value could never be changed after FC construction.
Root formatting context box is passed into constructor and saved in FC,
so it's possible to access it from there instead of passing the same
box into run().
That's awkward, but getComputedStyle needs to return used track values
for gridTemplateColumns and gridTemplateRows properties. This change
implements it by saving style values with used values into layout state,
so it could be assigned to paintables during LayoutState::commit() and
later accessed by style_value_for_property().
I haven't seen it used in the wild, but WPT grid tests extensively use
it. For example this change helps to go from 0/10 to 8/10 on this test:
https://wpt.live/css/css-grid/layout-algorithm/grid-fit-content-percentage.html
Fixes implementation of the following line from the spec:
"However, limit the growth of any fit-content() tracks by their
fit-content() argument."
Now we correctly apply a limit to increased growth limit rather than to
the planned increase.
Change in "Tests/LibWeb/Layout/input/grid/fit-content-2.html" is a
progression and "Item as wide as the content." is actually as wide as a
content.
When deciding if the grid containers min size should be limited by a
max size. Check for a max height or width depending on the dimension,
instead of just always checking for a max width.
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.
Implements:
"If the product of the hypothetical fr size and a flexible track’s flex
factor is less than the track’s base size, restart this algorithm
treating all such tracks as inflexible."
Fixes https://github.com/LadybirdBrowser/ladybird/issues/1211
Sticky positioning is implemented by modifying the algorithm for
assigning and refreshing scroll frames. Now, elements with
"position: sticky" are assigned their own scroll frame, and their
position is refreshed independently from regular scroll boxes.
Refreshing the scroll offsets for sticky boxes does not require display
list invalidation.
A separate hash map is used for the scroll frames of sticky boxes. This
is necessary because a single paintable box can have two scroll frames
if it 1) has "position: sticky" and 2) contains scrollable overflow.
