LibWeb keeps growing and the Web namespace is filling up fast.
Let's put DOM stuff into Web::DOM, just like we already started doing
with SVG stuff in Web::SVG.
Sometimes people make tables with a specific width. In those cases,
we can't just use the auto-sizing algorithm, but instead have to
respect whatever width the content specifies.
This is a bit rickety right now, since we don't implement generation
of anonymous table boxes.
The basic mechanism here is that block layout (which table-cell uses)
now has a virtual way of asking for the width of the logical containing
block. This is necessary as table-row does not produce a block-level
element and so was previously unable to provide a containing block
width for table-cell layout.
If the table has a non-auto specified width, we now interpret that as
a request to use fixed table layout. This will evolve over time. :^)
To make this possible, I also had to give each LayoutNode a Document&
so it can resolve document-specific colors correctly. There's probably
ways to avoid having this extra member by resolving colors later, but
this works for now.
"Paint" matches what we call this in the rest of the system. Let's not
confuse things by mixing paint/render/draw all the time. I'm guilty of
this in more places..
Also rename RenderingContext => PaintContext.
The shrink-to-fit width algorithm actually works a little bit different
in the absolute positioning context, so it can't share all of its code
with non-absolute positioning.
Also, inline-block elements were always inserting unnecessary line
breaks when splitting, which caused the preferred width to be smaller
than it should be. This patch fixes that as well, by just not breaking
after inline-block elements in LayoutMode::OnlyRequiredLineBreaks.
CSS defines a very specific paint order. This patch starts steering us
towards respecting that by introducing the PaintPhase enum with values:
- Background
- Border
- Foreground
- Overlay (internal overlays used by inspector)
Basically, to get the right visual result, we have to render the page
multiple times, going one phase at a time.
Previously, layout recursively performed these steps (roughly):
1. Compute own width
2. Compute own position
3. Layout in-flow children
4. Compute own height
5. Layout absolutely positioned descendants
However, step (2) was pretty inconsistent. Some things computed their
own position, others had their parent do it for them, etc.
To get closer to CSS spec language, and make things easier in general,
this patch reorganizes the algorithm into:
1. Compute own width & height
2. Compute width & height of in-flow managed descendants
3. Move in-flow managed descendants to their final position
4. Layout absolutely positioned descendants
Block layout is now driven by the containing block, which will iterate
the descendants it's responsible for. There are a lot of inefficient
patterns in this logic right now, but they can easily be replaced with
better iteration functions once we settle on a long-term architecture.
Since the ICB (LayoutDocument) is at (0, 0), it doesn't rely on a
containing block to move it into place.
This code is still evolving along with my understanding of CSS layout,
so it's likely that we'll reorganize this again sooner or later. :^)
Fixed position elements have the ICB as their containing block.
The magic of fixed positioning is implemented at the rendering stage,
where we temporarily translate painting by the current scroll offset.
Note that "absolutely positioned" includes both position:absolute
and position:fixed.
Absolutely positioned blocks now register themselves with their
containing block (and note that the containing block of an absolutely
positioned box is the nearest non-statically positioned block ancestor
or the ICB as fallback.)
Containing blocks then drive the layout of their tracked absolutely
positioned descendants as a separate layout pass.
This is very far from perfect but the general direction seems good.
We now implement the somewhat fuzzy shrink-to-fit algorithm when laying
out inline-block elements with both block and inline children.
Shrink-to-fit works by doing two speculative layouts of the entire
subtree inside the current block, to compute two things:
1. Preferred minimum width: If we made a line break at every chance we
had, how wide would the widest line be?
2. Preferred width: We break only when explicitly told to (e.g "<br>")
How wide would the widest line be?
We then shrink the width of the inline-block element to an appropriate
value based on the above, taking the available width in the containing
block into consideration (sans all the box model fluff.)
To make the speculative layouts possible, plumb a LayoutMode enum
throughout the layout system since it needs to be respected in various
places.
Note that this is quite hackish and I'm sure there are smarter ways to
do a lot of this. But it does kinda work! :^)
This display type is implemented using a LayoutBlock that is_inline().
Basically it behaves like a block internally, and its children are laid
out in the normal block layout fashion. Externally however, it behaves
like an atomic inline-level box.
Layout of inline-block boxes happens in three stages:
1. The outer dimensions of the block are computed during the recursive
normal layout pass. We skip positioning, but lay out children.
2. Later on, during line layout in the *containing block*, the inline
block now contributes a linebox fragment. When linebox fragments are
positioned, we learn the final position of the inline block. That's
when we set the inline block's position.
3. We re-layout the inline block's children once again. This is done to
make sure they end up in the right position. The layout tree doesn't
use relative offsets, so after we position the inline block in (2),
its children will not have its positions updated. Relayout moves
all children of inline blocks to the right place.
This is a rather naive approach but it does get the basic behavior into
place so we can iterate on it. :^)
