Bring the names of various boxes closer to spec language. This should
hopefully make things easier to understand and hack on. :^)
Some notable changes:
- LayoutNode -> Layout::Node
- LayoutBox -> Layout::Box
- LayoutBlock -> Layout::BlockBox
- LayoutReplaced -> Layout::ReplacedBox
- LayoutDocument -> Layout::InitialContainingBlockBox
- LayoutText -> Layout::TextNode
- LayoutInline -> Layout::InlineNode
Note that this is not strictly a "box tree" as we also hang inline/text
nodes in the same tree, and they don't generate boxes. (Instead, they
contribute line box fragments to their containing block!)
This is a first (huge) step towards modernizing the layout architecture
and bringing it closer to spec language.
Layout is now performed by a stack of formatting contexts, operating on
the box tree (or layout tree, if you will.)
There are currently three types of formatting context:
- BlockFormattingContext (BFC)
- InlineFormattingContext (IFC)
- TableFormattingContext (TFC)
Document::layout() creates the initial BlockFormattingContext (BFC)
which lays out the initial containing block (ICB), and then we recurse
through the tree, creating BFC, IFC or TFC as appropriate and handing
over control at the context boundaries.
The majority of this patch is just refactoring the old logic spread out
in LayoutBlock and LayoutTableRowGroup, and turning into these context
classes instead. A lot more cleanup will be needed.
There are many architectural wins here, the main one being that layout
is no longer performed by boxes themselves, which gives us much greater
flexibility in the outer/inner layout of a given box.
This allows layout nodes to do some setup before their children paint,
and cleanup after their children paint. This will be used for SVG
components, where their attributes (like stroke width, fill color, etc)
need to be correctly propogated to layout nodes down the line.
To implement form controls internally in LibWeb (necessary for multi
process forms), we'll need the ability to handle events since we can't
rely on LibGUI widgets anymore.
A LayoutNode can now override wants_mouse_events() and if it returns
true, it will now receive mousedown, mousemove and mouseup events. :^)
The text cursor follows slightly different "intuitive" rules than the
regular hit testing. Clicking past the right edge of a text box should
still "hit" the text box, and place the cursor at its end, for example.
We solve this by adding a HitTestType enum that is passed to hit_test()
and determines whether past-the-edge candidates are considered.
Const pointers into the DOM was a nice idea, but in practice, there are
too many situations where the layout tree wants to some non-const thing
to the DOM.
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.
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.
This patch also adds the ability for Length to contain percentage
values. This is a little off-spec, but will make storing and dealing
with lengths a lot easier.
To resolve a Length to a px-or-auto Length, there are now helpers
for that. After calling them, you no longer have to think about
em, rem, %, and such things.
StyleProperties is really only the specified "input" to what eventually
becomes the used/computed style we use for layout and painting.
Unlike StyleProperties, LayoutStyle will have strongly typed values for
everything it contains (i.e no CSS::ValueID or strings, etc.)
This first patch moves z-index into LayoutStyle.
This avoids having to query the StyleProperties hash map whenever we
need to know if an element is absolutely positioned. This was extremely
hot in interactive window resize profiles.
"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.
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.
Hey, why not. We did all the hard work for display:inline-block already
and now we can just allow this.
This makes <a><h1>Hello friends!</h1></a> work :^)
To support z-ordering when painting, the layout tree now has a parallel
sparse tree of stacking contexts. The rules for which layout boxes
establish a stacking context are a bit complex, but the intent is to
encapsulate the decision making into establishes_stacking_context().
When we paint, we start from the ICB (LayoutDocument) who always has a
StackingContext and then paint the tree of StackingContexts where each
node has its children sorted by z-index.
This is pretty crude, but gets the basic job done. Note that this does
not yet support hit testing; hit testing is still done using a naive
treewalk from the root.
The only layout nodes that don't have their own style are LayoutText
(they inherit the style from their parent element since text cannot
be styled by CSS.)
However, it never makes sense for text nodes to have absolute position
so don't claim it.
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.
The box tree and line boxes now all store a relative offset from their
containing block, instead of an absolute (document-relative) position.
This removes a huge pain point from the layout system which was having
to adjust offsets recursively when something moved. It also makes some
layout logic significantly simpler.
Every box can still find its absolute position by walking its chain
of containing blocks and accumulating the translation from the root.
This is currently what we do both for rendering and hit testing.
This patch introduces support for more than just "absolute px" units in
our Length class. It now also supports "em" and "rem", which are units
relative to the font-size of the current layout node and the <html>
element's layout node respectively.
LayoutReplaced now has intrinsic width, height and ratio. Only some of
the values may be present. The layout algorithm takes the various
configurations into account per the CSS specification.
This is still pretty immature but at least we're moving forward. :^)
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! :^)
