The name "initial containing block" was wrong for this, as it doesn't
correspond to the HTML element, and that's specifically what it's
supposed to do! :^)
If a box has clearance and margin bottom of preceding box is greater
than static y of the box then it should also affect y offset in current
block container so subsequent boxes will get correct y position too.
Though table wrappers are anonymous block containers (because
TableWrapper is inherited from BlockContainer) with no lines they
should not be skipped in block auto height calculation.
Previously block auto height calculation was changed to skip boxes with
collapsed margins and then condition to skip anonymous boxes with no
lines was also removed in 6c5ba10bb0 to
avoid skipping anonymous wrappers of tables.
Skipping boxes with collapsed margins (currently it's check that
height is 0) is wrong because it makes empty boxes with clearance to
be skipped which is not correct while anonymous boxes with no lines
should be skipped and it's no longer causes problems with tables
(fixed in 87f0e835eb)
Commit 7dc0edcb86 was supposed to prevent
floats from being placed higher than preceding boxes but the change
turned out to be completely wrong and caused regressions because:
1. Call to `clear()` in `layout_block_level_children` would reset
floating boxes only after layout of box with _not_ inline children
although the same should happen after layout of IFC.
2. `clear()` causes offset y of floats to be reset but it also clears
all currently enocuntered floating boxes which means the next box
that has actual clearance will get wrong y position.
There is a difference in y offset position calculation for floats when
LineBuilder provides final y position while for blocks it needs to be
adjusted by `y_offset`. This difference already accounted in floating
box position calculation and this patch also makes it accounted in check
whether a floating boxes on the same line intersect between each other.
Change `compute_auto_height_for_block_level_element` to use max height
(`m_automatic_content_height` produced from TFC) for tables with auto
height which is more correct behaviour than treating them like block
containers.
CSS 2.2 section 9.5.1:
The outer top of a floating box may not be higher than the
outer top of any _block_ or floated box generated by an
element earlier in the source document.
Where block is `BlockContainer` in LibWeb type system.
Which means `current_boxes` need to be cleared before
leaving block container.
```html
<style>
.wrapper {
width: 100px;
height: 300px;
background-color: lightgray;
}
.box {
margin: 10px;
width: 50px;
height: 50px;
float: left;
}
.a { background-color: salmon; }
.b { background-color: slateblue; }
.c { background-color: green; }
</style>
<div class="wrapper">
<div class="box a"></div>
<div class="box b"></div>
</div>
<div class="box c">
</div>
```
Introduce `TableWrapper` type so table wrappers could be
distinguished from block containers and override width
calculation for table wrappers (CSS 2.2 spec, section 17.5.2)
inside BFCs in the way that their width should be equal to
width of table box they wrap.
This change fixes problem that y position of blocks with
clearance might not include border_top and padding_top
by changing `place_block_level_element_in_normal_flow_vertically`
to accept y position without `border_box_top` and adding it
on the last step when clearance is already taken in account.
Bug reproducer:
```html
<style>
.a {
border: 10px salmon solid;
width: 50px;
height: 50px;
float: left;
}
.b {
clear: both;
border: 20px slateblue solid;
width: 50px;
height: 50px;
}
</style>
<div class="a"></div><div class="b"></div><div class="c"></div>
```
It is incorrect to skip anonymous block containers without
line boxes during block auto height calculation because there
might be table roots wrapped in anonymous table boxes after fixup
and their height should be taken in account so leaving just
condition to skip child boxes which margins are "collapsed
through" (`border_box_height() == 0`) sufficient to skip
anonymous blocks without lines but still consider table wrappers.
Implement collapsing of a box margin-top and first in-flow
child margin-top by saving function that updates y position
of containing block inside BlockMarginState and then for
every child until "non-collapsed through" child is reached
y position of containing block is updated by calling
update_box_waiting_fox_final_y_position_callback.
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.
Bug was introduced in 210bf8adf0c431be05659140fd6de3a2cc5b7d99
It makes new variable for independent_formatting_context instead
of using earlier declared one which means that
parent_context_did_dimension_child_root_box will never be called.
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.
Even if block has all children inline there need to be a check
if it creates BFC because otherwise IFC will be looking in
wrong parent BFC to calculate space used by floats.
We were neglecting to resolve the used horizontal padding and border
properties on block-level boxes when treating their width as `auto`
during intrinsic sizing.
This led to padding and border not contributing to the intrinsic width
of their containing block
Calling parent_context_did_dimension_child_root_box immediately after
laying out the inside of the floating box is not correct, as we haven't
worked out the dimensions of the floating box yet.
In particular, this caused the icons in the top bar of Cookie Clicker
to not hug the top of the viewport. This is because the icons are
absolutely positioned elements inside a floating element which has
padding applied to it. Since we laid out the abspos element before
the floating element, it got padding values of 0 from the parent, the
default value, meaning it didn't take away the padding of it's floating
parent.
This follows how abspos boxes layout their inside boxes as well.
We were incorrectly resolving them against the available width, which
may or may not be the same as the containing block width.
The specification for these properties says that percentages resolve
against the containing block width, so that's what we should do.
After speaking with fantasai at CSSWG about this, it turns out I had
misunderstood intrinsic heights. I originally believed all intrinsic
sizes had to be computed with no influence from the surrounding context.
As it turns out, intrinsic heights *are* influenced by the available
width, since it's needed to determine where lines break.
The APIs for calculating min-content and max-content heights now take
the available width as inputs. This instantly improves layout in many
cases where we'd previously make things way too wide.
When an absolutely positioned box has auto insets on both sides of an
axis, it's placed according to the "static position rectangle". This is,
roughly, the rectangle a box would occupy if it were position:static
instead of position:absolute or position:fixed.
This patch implements a rough, but still significantly better,
estimation of such static positions. It gets pretty hairy in the case
where an abspos box has a parent whose children are inline.
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 patch changes the *computed* representation of the following CSS
properties to use CSS::Size:
- width, min-width, max-width
- height, min-height, max-height
A few things had to change in order for things to keep working,
but I tried to keep the diff to a minimum.
The main trouble was that `min-width` and `max-width` can't actually be
`auto`, but they *can* be `none`. We previously treated `auto` as a
valid value (and it behaved mostly like `none`).
This was used by FFC to estimate the height of flex items after
performing layout inside them.
Now that we have automatic_content_height(), we no longer need this
awkward API and we can fold it into BFC's own height calculation.
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.
We were forgetting to convert to and from BFC root relative coordinates
when calculating how much clearance was needed to get past floats.
This fixes the last remaining issue on Acid1, which is now perfect. :^)
We already had a helper for this, but compute_height() wasn't using it.
Tweak it so that compute_height() can use it, and remove the duplicated
code that's now redundant.
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.
By asking if the value *contains* a percentage rather than whether it
*is* one, we cover many more cases where e.g `width: calc(100% - 10px)`
should be "treated as auto" etc.
