Previously, calling `.right()` on a `Gfx::Rect` would return the last
column's coordinate still inside the rectangle, or `left + width - 1`.
This is called 'endpoint inclusive' and does not make a lot of sense for
`Gfx::Rect<float>` where a rectangle of width 5 at position (0, 0) would
return 4 as its right side. This same problem exists for `.bottom()`.
This changes `Gfx::Rect` to be endpoint exclusive, which gives us the
nice property that `width = right - left` and `height = bottom - top`.
It enables us to treat `Gfx::Rect<int>` and `Gfx::Rect<float>` exactly
the same.
All users of `Gfx::Rect` have been updated accordingly.
There are a couple of things that went into this:
- We now calculate the intrinsic width/height and aspect ratio of <svg>
elements based on the spec algorithm instead of our previous ad-hoc
guesswork solution.
- Replaced elements with automatic size and intrinsic aspect ratio but
no intrinsic dimensions are now sized with the stretch-fit width
formula.
- We take care to assign both used width and used height to <svg>
elements before running their SVG formatting contexts. This ensures
that the inside SVG content is laid out with knowledge of its
viewport geometry.
- We avoid infinite recursion in tentative_height_for_replaced_element()
by using the already-calculated used width instead of calling the
function that calculates the used width (since that may call us right
back again).
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.
When there are floats present inside an IFC, we must coordinate with
the parent BFC to calculate the automatic width of the IFC's block box.
This is because the IFC is not directly aware of floats. Only the BFC
knows enough about them to account for them in automatic sizing.
Log a FIXME on the debug log, along with a layout tree dump of the box
that we didn't expect to see. This will be annoying (until fixed),
but far less so than crashing the browser.
Previously y position of boxes in block formatting context
was calculated by looking at y position of previous in-flow
sibling and adding collapsed margin of "collapse through"
boxes lying between box currently being laid out and it's
previous in-flow sibling.
Here introduced BlockMarginState structure that maintains
array of currently collapsible margins hence we no longer
need to look at previous sibling to calculate y position
of a box.
This fixes a few sizing issues too. The page size is now correct in most
cases! \o/
We get to remove some of the `to_type<>()` shenanigans, though it
reappears in some other places.
Before this, whenever encountering something other than dumb text
content in an inline flow, we assumed it had to be either a replaced
element, or an inline-block.
This removes the special-casing of inline-block so that IFC can size and
layout anything as long as it's inline on the outside.
There's no need to make the assumption that any inline-block box will
be represented by a BlockContainer. Nothing we do with the box here
requires that specific type anyway.
This is a big and messy change, and here's the gist:
- AvaliableSpace is now 2x AvailableSize (width and height)
- Layout algorithms are redesigned around the idea of available space
- When doing layout across nested formatting contexts, the parent
context tells the child context how much space is available for the
child's root box in both axes.
- "Available space" replaces "containing block width" in most places.
- The width and height in a box's UsedValues are considered to be
definite after they're assigned to. Marking something as having
definite size is no longer a separate step,
This probably introduces various regressions, but the big win here is
that our layout system now works with available space, just like the
specs are written. Fixing issues will be much easier going forward,
since you don't need to do nearly as much conversion from "spec logic"
to "LibWeb logic" as you previously did.
Instead of formatting contexts flailing around to figure out from the
"inside" how much space is available on the "outside", we should
provide the amount of available space in both axes as an input to run().
This basically means that when something creates a nested formatting
context, the parent context is responsible for telling the nested context
how much space is available for layout. This information is provided
immediately when invoking run().
Note that this commit doesn't pass accurate values in all cases yet.
This first step just makes it build, and passes available values in some
cases where getting them was trivial.
This function should return the automatic height of the formatting
context's root box.
Until now, we've been relying on some magical handshakes between parent
and child context, when negotiating the height of child context root
boxes. This is a step towards something more reasonable.
This patch combines a number of techniques to make inline content flow
more correctly around floats:
- During inline layout, BFC now lets LineBuilder decide the Y coordinate
when inserting a new float. LineBuilder has more information about the
currently accumulated line, and can make better breaking decisions.
- When inserting a float on one side, and the top of the newly inserted
float is below the bottommost float on the opposite side, we now reset
the opposite side back to the start of that edge. This improves
breaking behavior between opposite-side floats.
- After inserting a float during inline layout, we now recalculate the
available space on the line, but don't adjust X offsets of already
existing fragments. This is handled by update_last_line() anyway,
so it was pointless busywork.
- When measuring whether a line can fit at a given Y coordinate, we now
consider both the top and bottom Y values of the line. This fixes an
issue where the bottom part of a line would bleed over other content
(since we had only checked that the top Y coordinate of that line
would fit.)
There are some pretty brain-dead algorithms in here that we need to make
smarter, but I didn't want to complicate this any further so I've left
FIXMEs about them instead.
This remained undetected for a long time as HeaderCheck is disabled by
default. This commit makes the following file compile again:
// file: compile_me.cpp
#include <LibWeb/CSS/GridTrackSize.h>
// That's it, this was enough to cause a compilation error.
Before this change, we'd always insert one line box fragment, even when
a float was taking up too much space on the line, and the fragment
didn't actually fit.
We now perform line breaks until we have enough space between floats.
This fixes many page layouts where we'd previously see small fragments
of inline content outside the right edge of the containing block.
- Use the border box of the floated element when testing if something
needs to flow around it.
- Take the floated element's containing block size into account (instead
of the BFC root) when calculating available space on a line where a
right-side float intrudes.
When calculating intrinsic sizes, we don't need to recurse into *every*
box and layout its insides. IIUC, we can skip any unconstrained box with
definite sizes in both axes. So this patch does exactly that.
Previously, we had three layout modes:
- Normal:
- Everything uses the computed values from CSS.
- MinContent:
- Containing blocks act as if they have 0 width.
- All line breaking opportunities are taken.
- MaxContent:
- Containing blocks act as if they have infinite width.
- Only forced line breaks are accepted.
The above was based on a set of misunderstandings of CSS sizing.
A major problem with the above was that *all* containing blocks
behaved differently during intrinsic size layout, not just the
relevant one.
With this patch there are only two layout modes:
- Normal:
- Everything uses the computed values from CSS.
- IntrinsicSizeDetermination:
- One or more boxes have size constraints applied.
There are two size constraints per layout box, set here:
- FormattingState::NodeState::width_constraint
- FormattingState::NodeState::height_constraint
They are of type SizeConstraint and can be one of None, MinContent,
or MaxContent. The default is None.
When performing an IntrinsicSizeDetermination layout, we now assign
a size constraint to the box we're trying to determine the intrinsic
size of, which is then honored by using two new helpers to query
the dimensions of containing blocks:
- FormattingContext::containing_block_width_for(Box)
- FormattingContext::containing_block_height_for(Box)
If there's a relevant constraint in effect on the Box, the size of
its containing block is adjusted accordingly.
This is essentially an implementation of the "available space"
constraints from CSS-SIZING-3. I'm sure some things will break from
this, and we'll have to deal with that separately.
Spec: https://drafts.csswg.org/css-sizing-3/#available
Before this change, IFC would first generate all of its line boxes
and then measure them. It would then write some of the values into
the state of the IFC's containing block.
We now move that up to BFC::layout_inline_children() instead, which
is a much more natural place to decide metrics for the block.
Instead of using Optional<LengthPercentage>, we now use LengthPercentage
for these values. The initial values are all `auto`.
This avoids having to check `has_value()` in a ton of places.
If white-space is nowrap then we don't want to break a text_node
into multiple line boxes. This fixes the width calculation in the
min-content case for white-space: nowrap elements. Before this
the min-width would be the width of the biggest line box.
We now position inline-level boxes based on ascent and descent metrics
from the font in use. This makes our basic text layouts look a lot more
like those produced by other browsers. :^)
I've tried to match the terminology used by the CSS Inline Layout spec.
This will regress Acid2 a little bit, and probably various other sites,
but on the whole it's the direction we should be heading, so let's go.
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.
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.
The old mode names, while mechanically accurate, didn't really reflect
their relationship to the CSS specifications.
This patch renames them as follows:
Default => Normal
AllPossibleLineBreaks => MinContent
OnlyRequiredLineBreaks => MaxContent
There's also now an explainer comment with the LayoutMode enum about the
specific implications of layout in each mode.
After accounting for left-side floats, we have to subtract the offset of
the IFC's containing block again, to get the real starting X offset
for the current line.
This was done correctly in leftmost_x_offset_at() but incorrectly in
available_space_for_line(), causing IFC to break lines too early in
cases where the containing block had a non-zero X offset from the BFC
root block.
This makes SVG-in-HTML behave quite a bit better by following general
replaced layout rules. It also turns <svg> elements into inline-level
boxes instead of block-level boxes.
The previous implementation used relative X offsets for both left and
right-side floats. This made right-side floats super awkward, since we
could only determine their X position once the width of the BFC root was
known, and for BFC roots with automatic width, this was not even working
at all most of the time.
This patch changes the way we deal with floats so that BFC keeps track
of the offset-from-edge for each float. The offset is the distance from
the BFC root edge (left or right, depending on float direction) to the
"innermost" margin edge of the floating box.
Floating box are now laid out in two passes: while going through the
normal flow layout, we put floats in their *static* position (i.e the
position they would have occupied if they weren't floating) and then
update the Y position value to the final one.
The second pass occurs later on, when the BFC root has had its width
assigned by the parent context. Once we know the root width, we can
set the X position value of floating boxes. (Because the X position of
right-side floats is relative to the right edge of the BFC root.)
