We're using the outermost right and bottom child edges to determine the
width and height of the ICB. However, since these edges are *within* the
respective child's rectangle, we have to add 1 when turning them into
width and height values.
This fixes an issue where scrolling a document would shrink its viewport
rect by 1 pixel (on both axes) on every scroll step.
This always felt awkward to me, and required a few other hacks to make
it work. Now, the request is only started when `load_bitmap()` is
called, which we do inside `NodeWithStyle::apply_style()`.
This patch breaks FormattingContext::layout_inside() into two functions,
one that creates an independent formatting context (if needed), and
another that calls the former and then performs the inside layout within
the appropriate context.
The main goal here was to make layout_inside() return the independent
formatting context if one was created. This will allow us to defer
certain operations in child contexts until the parent context has
finished formatting the child root box.
Per spec, the initial containing block (ICB) should have the size of the
viewport. We have only done this for the width until now, since we had
no way to express scrollable overflow.
This patch adds Layout::Box::m_overflow_data, an optional struct that
can hold on to information about a box's overflow. Then we have BFC
set the ICB up with some scrollable overflow instead of sizing it to fit
its content vertically.
This fixes a number of broken layouts where correctness depends on
having the appropriate ICB height.
Apparently it's not only replaced elements that can have intrinsic
sizes, so let's move this concept from ReplacedBox to Box. To avoid
bloating Box, we make the accessors virtual.
Since FFC is only ever run() on the flex container, we can assume (but
verify) that the run box is the flex container and use an accessor
throughout. The end result: less parameter passing.
Determining the available main and cross space is now done by a separate
function. The signature is a little bit hairy since this function
computes some things that are used by subsequent algorithm steps.
Factoring can definitely be improved further.
Per css-sizing-3:
Additionally, the size of the containing block of an absolutely
positioned element is always definite with respect to that element.
As I understand this, it doesn't mean that all absolutely positioned
boxes have definite size, but that the containing block of an absolutely
positioned descendant has definite size from the perspective of the
descendant.
When computing whether whitespace should be collapsed or not, we have to
consider empty fragments, since <br> will produce an empty fragment to
force a line break.
LineBox::is_empty_or_ends_in_whitespace() is amended to look at the
length of the last fragment, and return true if it is 0.
Per the spec, only a BlockContainer" can have line boxes, so let's not
clutter up every Layout::Box with line boxes.
This also allows us to establish an invariant that BFC and IFC always
operate on a Layout::BlockContainer.
Note that if BlockContainer has all block-level children, its line boxes
are not used for anything. They are only used in the all inline-level
children scenario.
