Instead of storing these as individual `background-foo` properties, we
combine them together into layers, since that is how they will be
painted. It also makes it more convenient to pass them around.
While right now this doesn't save much complexity, it will do once we
care about multiple background layers per node. Then, having a single
repeat value per layer will simplify things.
It also means we can remove the pseudo-property concept entirely! :^)
We achieve this by simply setting the intrinsic size to the size needed
to render the replacement text.
This fixes a long-standing issue where non-loaded images would default
to the goofy-looking 300x150 fallback size for replaced elements.
We now compute the used height of height:auto by measuring from the top
content edge (y=0) to the bottom of the bottommost line box within the
block container.
This fixes an issue where we'd fail to account for the topmost line box
being taller than any of its fragments (which can happen if the
line-height is greater than the height of all fragments on the line.)
I don't remember why we did things this way, but it's clearly not right
to stretch fragments vertically. Instead, we should just align their
bottom to the appropriate line (as we already do.)
This was a hack to percentages within tables relative to the nearest
table-row ancestor instead of the nearest table container.
That didn't actually make sense, so this patch simply removes the hack
in favor of containing_block()->width().
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.
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.
