Simplify automatic cross sizing of items in flex-direction:column by
using the fit-content width directly.
There's obviously a lot more nuance to this, but for now this makes
flex items with both width:auto and height:auto actually get some height
in column flex layouts.
I'm a little confused about intrinsic heights *really* work, and I'm
struggling to extract that information from the spec. In the meantime,
let's ensure that min-content is always smaller than (or equal to)
max-content so that other math works as expected.
Previously, each NodeState in a FormattingState was shared with the
parent FormattingState, but the HashMap of NodeState had to be copied
when making FormattingState copies.
This patch makes copying instant by keeping a pointer to the parent
FormattingState instead. When fetching immutable state via get(), we may
now return a reference to a NodeState owned by a parent FormattingState.
get_mutable() will copy any NodeState found in the ancestor chain before
making a brand new one.
The flexbox specification barely even handwaves about automatically
sized items, but there's actually a lot of work to do in order for them
to get the correct size.
This patch is messy, but does make significant progress on supporting
flex items with indefinite width and/or height.
There's a fair amount of nested layout going on here, but do note that
we'll be hitting the intrinsic sizes cache whenever possible.
FormattingContext can now calculate the intrinsic sizes (min-content and
max-content in both axes) for a given Layout::Box.
This is a rather expensive operation, as it necessitates performing two
throwaway layouts of the subtree rooted at the box. Fortunately, we can
cache the results of these calculations, as intrinsic sizes don't change
based on other context around the box. They are intrinsic after all. :^)
This wasn't worth the headache of trying to make SVG boxes work together
with BFC right now. Let's just make it a block container once again, and
have its corresponding SVGPaintable inherit from PaintableWithLines.
We'll have to revisit this as SVG support improves.
Although something has a definite size, we may still have to "resolve"
it, since FFC is quite liberal in what it considers to be definite.
Let's put that logic in a set of helper functions.
1. Make this decision *after* we've inserted the layout node into the
layout tree. Otherwise, we can't reach its containing block!
2. Per css-sizing-3, consider auto-sized blocks whose sizes resolve
solely against other definite sizes as definite themselves.
In particular, (2) makes us consider width:auto block children of a
definite-size containing block as having definite size. This becomes
very important in flex layout.
If there's some non-block-level box (like an SVG element of some kind)
between to blocks, just skip over the non-block for purposes of margin
collapsing. This is basically a hack, and something we'll need to
improve as part of our general SVG support.
For single-line flex containers, center the only flex line along the
cross axis. Alignment of multi-line flex containers are left as a FIXME.
This patch also moves out the assignment of final metrics to the
FormattingState from align_all_flex_lines() to a separate function.
- Avoid performing inside layout on definite-size flex items (since
their computed size can be used as-is.)
- Use FormattingState::clone() to generate a throwaway layout instead of
mutating the tree in-place.
- Update spec link & comments based on current CSSWG draft. The latest
version is quite a bit clearer on how this should work.
Instead of doing internal child layout incrementally as we go, save it
for the end of flex layout. The code will become simpler if we can focus
on simply computing the dimensions of each flex item while we're doing
the main FFC algorithm.
We don't need to perform inside layout here. The only information we
need in this step is whether an anonymous block container has nothing
but empty-or-whitespace text children.
This information is already accurate after the initial layout tree
construction. Performing a layout does not change the answer. It does
however have many other side effects, so let's defer those.
This implements at least some of the specification. inter-character is
not yet handled. However as our current algorithm only considers
whitespace as word breaks, inter-word could technically be considered to
be handled. :^)
All the justification-related code is now in
InlineFormattingContext::apply_justification_to_fragments and is
performed after all the line boxes have been added.
Text justification now only happens on the last line if the excess space
including whitespace is below a certain threshold. 10% seemed reasonable
since it prevents the "over-justification" of text. Note that fragments
in line boxes before the last one are always justified.
Everything related to hit testing is better off using the painting tree.
The thing being mousemoved over is a paintable, so let's hand that out
directly instead of the corresponding layout node.
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
This patch adds a bunch of Paintable subclasses, each corresponding to
the Layout::Node subclasses that had a paint() override. All painting
logic is moved from layout nodes into their corresponding paintables.
Paintables are now created by asking a Layout::Box to produce one:
static NonnullOwnPtr<Paintable> Layout::Box::create_paintable()
Note that inline nodes still have their painting logic. Since they
are not boxes, and all paintables have a corresponding box, we'll need
to come up with some other solution for them.
BlockContainer paint boxes are the only ones that have line boxes
associated, so let's not waste memory on line boxes in all the other
types of boxes.
This also adds Layout::Box::paint_box() and the more tightly typed
Layout::BlockContainer::paint_box() to get at the paint box from the
corresponding layout box.
The "paintable" state in Layout::Box was actually not safe to access
until after layout had been performed.
As a first step towards making this harder to mess up accidentally,
this patch moves painting information from Layout::Box to a new class:
Painting::Box. Every layout can have a corresponding paint box, and
it holds the final used metrics determined by layout.
The paint box is created and populated by FormattingState::commit().
I've also added DOM::Node::paint_box() as a convenient way to access
the paint box (if available) of a given DOM node.
Going forward, I believe this will allow us to better separate data
that belongs to layout vs painting, and also open up opportunities
for naturally invalidating caches in the paint box (since it's
reconstituted by every layout.)
Note that we don't put absolutely positioned items on a line! This is
just so that IFC can discover boxes and pass them along to BFC.
This fixes an issue where only direct children of the IFC containing
block were considered for absolute positioning. Now we pick up
absolutely positioned children of nested inline nodes as well.
This patch adds support for "crisp-edges", "high-quality" and "smooth"
for the CSS image-rendering property.
"crisp-edges" maps to nearest-neighbor scaling for <canvas> and <img>
elements, while "high-quality" and "smooth" both use bilinear blending.
Previously, the decoration was painted behind the text. This probably
wasn't noticed before, as we didn't compute `text-decoration-color`
values yet and the decoration had the same color anyway.
Previosly, we used only the text color as a line decoration color.
The FIXME comment has been directly copy-pasted from the border color
note a few lines below.
If the content wants to be pixelated, we should honor that and paint
with nearest-neighbor scaling. The fact that it's faster is a nice bonus
as well. :^)
