LibWeb: Correctly lay out block elements inside inline elements

[gmta]

The contents of inline elements containing a block element were incorrectly ordered, e.g.

<b>foo<div>bar</div>baz</b>

...did not render the <div> as being in between the foo and baz fragments.

Before	After

Excerpt from Web::Layout::TreeBuilder:

---

Block nodes inside inline nodes are allowed, but to maintain the invariant that either all layout children are
inline or non-inline, we need to rearrange the tree a bit. All inline ancestors up to the node we've inserted are
wrapped in an anonymous block, which is inserted into the nearest non-inline ancestor. We then recreate the inline
ancestors in another anonymous block inserted after the node so we can continue adding children.

Effectively, we try to turn this:

InlineNode 1
  TextNode 1
  InlineNode N
    TextNode N
    BlockContainer (node)

Into this:

BlockContainer (anonymous "before")
  InlineNode 1
    TextNode 1
    InlineNode N
      TextNode N
BlockContainer (anonymous "middle") continuation
  BlockContainer (node)
BlockContainer (anonymous "after")
  InlineNode 1 continuation
    InlineNode N

To be able to reconstruct their relation after restructuring, layout nodes keep track of their continuation. The
top-most inline node of the "after" wrapper points to the "middle" wrapper, which points to the top-most inline node
of the "before" wrapper. All other inline nodes in the "after" wrapper point to their counterparts in the "before"
wrapper, to make it easier to create the right paintables since a DOM::Node only has a single Layout::Node.

Appending then continues in the "after" tree. If a new block node is then inserted, we can reuse the "middle" wrapper
if no inline siblings exist for node or its ancestors, and leave the existing "after" wrapper alone. Otherwise, we
create new wrappers and extend the continuation chain.

Inspired by: https://webkit.org/blog/115/webcore-rendering-ii-blocks-and-inlines/

[kalenikaliaksandr]

have you considered solving the problem on paintable tree level? I suppose webkit has to use continuations on layout tree because they do not have paintable tree concept, while we do and support 1:N relationship between layout and paintable nodes.

[gmta]

@kalenikaliaksandr @awesomekling I've rearranged some things:

• Determining the united border/padding/margin/content rects is now the responsibility of PaintableBox again.
• The continuation chain is still only part of the layout tree however; it's not clear to me if we're always going to have paintables for parts of split-up inline elements that might not be visible (e.g. in <b><div>foo</div>bar</b>) and if so, how we're going to reliably link up the right paintables during creation of the painting tree. I've left a FIXME in PaintableBox to this end.
• More DOM methods were updated and I've added a test for offsetTop/Left/Width/Height.

[kalenikaliaksandr]

could we add a test for hit-testing just so we can be sure it works as expected when it comes to continuations?

[gmta]

could we add a test for hit-testing just so we can be sure it works as expected when it comes to continuations?

Absolutely, in fact, I'm also working on a bugfix for something depending on this that involves hit-testing. I'll tack on the commit to this PR.