This function can really only be called with a box and its containing
block, otherwise the results are not meaningful. Instead of passing
these two dependent values separatly, reduce it down to a single
parameter to not make the function appear more general than it is.
If there are multiple nested `position: fixed` or `position: absolute`
elements that are positioned based on their static position due to not
specifying any insets, we sum up all their ancestor offsets to calculate
said static position.
However, these offsets represent the offset to the containing block. So
summing up all the ancestor blocks will count elements multiple times
for cases where the containing block is not based on the closest element
capable of forming a containing block (i.e. absolute and fixed position
elements) when multiple such elements are nested.
With this change we only iterate over ancestors forming containing
blocks instead of over all ancestors boxes. To sum up everything between
the box currently being positioned and its containing block, we start
the iteration on the parent box of the current box.
This fixes 3 WPT tests that I could find. But these tests are not
intended to test the error cases fixed here, they just incidentally rely
on the correct behavior. As such, I have added dedicated tests myself.
Note that two of the tests already pass on master, but they seemed like
a good cases to have anyway.
The CSS spec says the baseline of an inline-block should be the bottom
margin when either the overflow property is not 'visible' or there are
no in-flow line boxes. Previously, only the latter case was checked.
This fixes 1 WPT test:
https://wpt.live/css/css-align/baseline-of-scrollable-1a.html
A ::marker pseudo-element is created for list item nodes (nodes
with display:list-item).
Before:
- The content of the ::marker element is created magically from
the value of the ordinal (for <ol>) or from a template (for <ul>).
The style `content` is ignored for ::marker pseudo-elements.
After:
- If a "list item node" has CSS `content` specified for its ::marker
pseudo-element, use this to layout the pseudo-element,
https://drafts.csswg.org/css-lists-3/#content-property
- Otherwise, layout the list item node as before.
Before this change, you could only scroll the current hovered scroll
container, even if it was at the beginning or end and thus having no
effect.
Now, if it doesn't update, it will not be classed as handled and will
move onto the next scroll container.
This applies size, inline-size, and style containment in some cases.
There are other WPT tests for that, but we seem to not implement enough
of containment for this to have an effect so I've not imported those.
Gets us 35 WPT subtests.
Whether an absbox is positioned below or to the right of its previous
sibling in an `InlineFormattingContext` is determined by the
display-outside value before blockification, so we store the
pre-blockification `display` value in `ComputedValues` to access it in
`InlineFormattingContext` and position the box accordingly.
Before this change, we always used the flex container's full available
space as the width for intrinsic (height) sizing of flex items.
This meant that flex lines with more than one flex item had their
intrinsic height determined as if they were alone on the line.
For flex row layouts, if we've already determined the flex item's main
size, we now use that as the width to get the intrinsic height.
This leads to more correct layouts, and also avoids some redundant work
since we no longer do unnecessary sizing work with the wrong width (and
can hit cache instead).
...instead of taking the Layout::Box. This will allow us to make more
nuanced decisions in those functions by having access to flex layout
internal state.
This gets rid of the assumption that the DOM node of an ImageBox is
also its image provider. This will become necessary when generating
the image boxes for view transition pseudos, for which the DOM node
won't be the image provider. (that'll be the pseudo element itself)
These functions are trivial, and we were actually bleeding a lot of time
in profiles to just function entry/exit.
By marking Length::make_px() as [[nodiscard]], we also exposed some
places that were creating a Length and not using it for anything.
When displaying SVGs inside a navigable directly, we want to display
them in the size specified by their width and height attributes instead
of stretching them to the viewport as layout normally would.
However, when doing so, we need to actually check that the SVG we are
laying out is indeed directly inside the navigable. Otherwise we just
blindly overwrite whatever content sizes have been calculated by layout
code for e.g. SVG elements inlined somewhere in an HTML document.
Due to the way this was written originally, the bug was not very
noticable. The code overwrote the content width/height with the computed
width/height, which was often still correct in the sense that those two
had the same value. However, content size may also be the result of
{min,max}-{width,height} constraints, which can make it differ from the
computed values.
This bug was likely a regression introduced in
f5e01192cc.
We now also more closely follow the spec when computing values for
font-weight and we now:
- Support relative lengths in `calc()`s
- Properly clamp `calc()`s
- Support relative keywords (e.g. lighter, bolder)
- Respect that font-weight can be a non-integer number.
This does expose a few false positives in the font-weight-computed.html
WPT test. This is because we don't recompute non-inherited font-weight
within `recompute_inherited_style` which means that relative keyword
values can fall out of sync with their parent's value. These previously
passed as we treated `bolder` and `lighter` as aliases for `bold` and
`normal` respectively.
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.
This means that we now calculate the inner width correctly for `display:
inline-block` nodes when we have `box-sizing: border-box` and
`min-width`, as we would previously assume these dimensions were all `0`
This change removes premature reset of
`block_container_y_position_update_callback`. Also makes callback
private in `BlockMarginState`, because resetting it independently of
currently accumulated margins is incorrect.
Lots of test expectations are updated, but there is no visual
difference.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/6074
Callback registered by
`register_block_container_y_position_update_callback()` is executed
after `layout_block_level_box()` returned, so capturing stack variable
`y` by reference is UB.
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.
Interpolation can leave `padding-*` values as negative - this should be
handled by interpolation clamping it to the allowed range of values
but we don't yet do that. As a stop gap we can clamp this before setting
it in ComputedValues.
This fixes 3 crashes and gains us 11 passes in the imported WPT tests
