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.
