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.
Previously, when having inline contexts consisting of just a `<br/>`
tag, we would not create a line box.
Ensure that there is always a line box when a line is explicitly being
broken and also ensure it won't be trimmed due to being empty.
This will a fix a number of sites that use `<br>` tags for layouts
between block elements (even though the spec says they shouldn't).
We now distribute the line-height evenly between the space above and
below inline-level boxes. This noticeably improves our baseline
alignment in many cases.
Note that the "vertical-align: <length>" case is quite awkward, as the
extra height added by the offset baseline must count towards the line
box height.
There's a lot of room for improvement here, but this makes the buckets
container on Acid3 show up in the right place, with the right size.
Until now, we've been treating the bottom of every line box fragment as
its baseline, and just aligning all the bottoms to the bottom of the
line box. That gave decent results in many cases, but was not correct.
This patch starts moving towards actual baseline calculations as
specified by CSS2.
Note that once layout is finished with a line box, we also store the
baseline of the line box in LineBox::m_baseline. This allows us to align
the real baseline of display:inline-block elements with other inline
content on the same line.
Previously we were computing the bottom edge of a line box by finding
the bottommost fragment on the line.
That method didn't give correct results for line boxes with no fragments
(which is exactly what you get when inserting a bunch of <br> elements.)
To cover all situations, we now keep track of the bottommost edge in the
LineBox object itself.
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.
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. :^)
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.
In #10434 an issue with leading whitespace in new lines after
a <br> element was fixed by checking whether the last fragment
of LineBox is empty.
However, this introduced a regression by which whitespace following
inline elements was swallowed, so `<b>Test</b> 123` would appear
like `Test123`.
By asking specifically if we are handling a forced linebreak
instead of implicity asking for a property that may be shared by
other Node types, we can maintain the correct behavior in regards
to leading whitespace on new lines, as well as trailing whitespace
of inline elements.
There's a subtle difference here. A "block box" in the spec is a
block-level box, while a "block container" is a box whose children are
either all inline-level boxes in an IFC, or all block-level boxes
participating in a BFC.
Notably, an "inline-block" box is a "block container" but not a "block
box" since it is itself inline-level.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
