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.
The CSS spec uses the name "block formatting context root" when talking
about a box that establishes a BFC. So let's call it BFC::root() in our
code as well, instead of the less specific BFC::context_box().
Negative margins are a headache anyways, and allowing them to be
negative lead to weird behavior.
This patch avoids vasty wrong height-calculations by limiting the
allowed margins to positive numbers when evaluating the height of a
block.
Our "frame" concept very closely matches what the web specs call a
"browsing context", so let's rename it to that. :^)
The "main frame" becomes the "top-level browsing context",
and "sub-frames" are now "nested browsing contexts".
When computing the y-position of a clearing element, use the height of
the border box of the associated floating elements.
This also extracts this block of code to a helper lambda since it is
used twice.
This commit unifies methods and method/param names between the above
classes, as well as adds [[nodiscard]] and ALWAYS_INLINE where
appropriate. It also renamed the various move_by methods to
translate_by, as that more closely matches the transformation
terminology.
Now we use min-height for calculating the height of block boxes.
Besides, now we check if min-height/max-height are percentage values
and don't use them if parent's height isn't explicitly set (CSS 2.1
section 10.7).
Now we set margins, borders and paddings for floating boxes and include
them into calculating floating box positions by using margin_box() and
margin_box_as_relative_rect().
Height computation algorithm is actually
different for absolutely positioned boxes
and block formatting contexts (where it doesn't include floats)
Fixes#6408
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 *
This commit fixes algorithm for computing auto height (CSS 2.2 10.6.7)
by including floating boxes into computation and implements one of the cases
for computing the height of absolutely positioned, non-replaced elements (10.6.4 rule 3)
Turns out compute_position should be invoked before placing the element
in normal flow. Otherwise, the position isn't set on the first layout.
The effect was that the block would "jump" into place on a secondary
layout.
This is a follow-up to commit:
deda7c8995
Section 10.3 "Calculating widths and margins" indicates that the 'left'
and 'right' properties of relatively positioned elements should be set
in accordance with the rules of section 9.4.3.
The case for computing auto-height of block elements which have block-
level children was erroneously skipping some children:
1. If the block element itself is absolute or floating, all children
were skipped due to a likely typo ("box" vs. "child_box" inside the
for-each loop).
2. Floating children should only be skipped if the block element's
'overflow' property computes to 'visible', per section 10.6.3 of the
CSS height property spec. If the property computes to another value,
section 10.6.7 only indicates that absolutely positioned children
should be skipped.
Auto block heights are now computed according to something that kinda
resembles the specification.
Blocks with inline children and height:auto have their height computed
based on the top of the first line box and the bottom of the last line
box. Very straightforward.
Blocks with block children and height:auto have their height computed
based on the top of the first in-flow block child's margin box, and the
bottom of the last in-flow block child's margin box.
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
The approach of attaching sub-widgets to the web view widget was only
ever going to work in single-process mode, and that's not what we're
about anymore, so let's just get rid of WidgetBox so we don't have the
dead-end architecture hanging over us.
The next step here is to re-implement <input type=text> using LibWeb
primitives.
