When calculating the edge offset of the next floating item based on the
offset of the preceding floating item, we need to ensure that the
preceding offset is always > 0. This isn't explicitly written in the
spec, but all other popular engines do that.
Fixes https://github.com/SerenityOS/serenity/issues/21023
Before, we completely ignored clearance for block-level boxes if they
were floated. This was incorrect because it is valid for a block-level
box to be floated and still have clearance. However, unlike clearance
on normal flow boxes, clearance on floating boxes does not affect the
y-position of subsequent normal flow boxes. Instead, it pushes the
box's position to the very beginning of an edge.
Work towards https://github.com/SerenityOS/serenity/issues/21023
When a button should use flex for alignment and also has ::before
and/or ::after, we previously did the following:
1. Prepended/appended the button's children with boxes for
pseudo-elements.
2. Replaced the button's direct children with a flex container that
contains its children.
As a result, the generated boxes for ::before/::after ended up as
children of the generated flex item, instead of being direct children
of the button layout box as they were supposed to be.
This change reverses these steps, ensuring that boxes for
pseudo-elements are generated only after modifications inside the
button layout are completed.
Before, we were using the line height from NodeWithStyle::line_height()
to calculate the y offset for floats inside the IFC. However, this
value doesn't always correspond to the actual height of a line box. For
instance, adding a fragment for an inline-block might change the height
of the line box. With this change, we recalculate the height of the
line box after adding a new fragment and use this recalculated height
value to determine the y position for floats.
Fixes https://github.com/SerenityOS/serenity/issues/20982
Using flex layout inside button solves the issue with wrongly calculated
height when it has: pseudo element and whitespaces inside.
Also using flex instead of a table layout allows for the same vertical
alignment but with fewer layout nodes: a flex container and anonymous
wrapper for content instead of a table wrapper, table, row, and cell.
Previously we always set the height of the HTML element equal to the
viewport height but now this will only happen in quirks mode as it is
intended. Otherwise the html element height will be computed as auto.
Since we always pass the px value as an argument to resolved(), we can
pass it directly as CSSPixels instead of wrapping it in Length. This
approach allows us to avoid converting to a double, resulting in fewer
precision issues.
We were relying on the table fixup algorithm to insert the missing table
row, which fails to do so when we only have an image in the button.
While that might be a problem with the table fixup algorithm, we should
build a correct layout tree explicitly anyway.
Fixes crashes on GitHub.
When a box is sized under max-content constraint, any percentage value
set for max-width should be considered as if it were infinite. In other
words, it should have no effect on restricting the box's width.
Instead of applying relative offsets (like position:relative insets)
during painting and hit testing, we now do a pass at the end of layout
and assign the final resolved offsets to paintables.
This makes painting and hit testing easier since they don't have to
think about relative offsets, and it also fixes a bug where offsets were
not applied to text fragments inside inline-flow elements that were
themselves position:relative.
Allow the left margin of a box which creates a block formatting context
to overlap with left floating boxes which are siblings in the document
tree.
Fixes#20233 and the comment layout on https://lobste.rs.
Before this change, we always derived a box's baseline from its last
child, even if the last child didn't have any line boxes inside.
This caused baselines to slip further down vertically than expected.
There are more baseline alignment issues to fix, but this one was
responsible for a fair chunk of trouble. :^)
If an inline-block has a percentage height that relies on the auto
height of the containing block, it should always resolve to the
automatic height of the box, regardless of the percentage value. This
change may seem confusing, but it aligns with the behavior of other
engines.
When the containing block has an indefinite width, any descendants with
a percentage size should resolve that against 0, not infinity.
Fixes an assertion failure when loading https://www.gnu.org/
Absolutely positioned elements should have their percentage sizes
resolved against the padding box of the containing block, not the
content box.
From CSS-POSITION-3 <https://www.w3.org/TR/css-position-3/#def-cb>
"..the containing block is formed by the padding edge of the ancestor.."
The margin from the containing blocks shouldn't be included in the
amount by which we increment x after a float was places. That coordinate
should be relative to the containing block.
Fixes the comments layout on https://lobste.rs.
If a box has a negative margin-left, it may have a negative effective
offset within its parent BFC root coordinate system.
We can account for this when calculating the amount of left-side float
intrusion by flooring the X offset at 0.
This fixes the issue when margin collapsing state was always reset if
a box has clear property not equal to none even if it does not actually
introduce clearance.
This fixes the issue where max margin is used to find offset of
floating box although horizonal margins do not collapse so they need
to be summed instead.
In order to fix this, I also had to reorganize the code so that we
create an independent formatting context even for block-level boxes
that don't have any children. This accidentally improves a table
layout test as well (for empty tables).
While inline content between floating elements was broken correctly,
text justification was still using the original amount of available
space (without accounting for floats) when justifying fragments.
This code now works in terms of *intrusion* by left and right side
floats into a given box whose insides we're trying to layout.
Previously, it worked in terms of space occupied by floats in the root
box of the BFC they participated in. That created a bunch of edge cases
since the code asking about the information wasn't operating in root
coordinate space, but in the coordinate space of some arbitrarily nested
block descendant of the root.
This finally allows horizontal margins in the containing block chain to
affect floats and nested content correctly, and it also allows us to
remove a bogus workaround in InlineFormattingContext.
