Follow the computing column measures section of the specification, which
gives an algorithm for setting intrinsic percentage widths when spanning
columns are involved.
Change how we store type of columns. It was used where the specification
only distinguishes between percent and everything else, so it makes more
sense to store and use it as a boolean.
The specification says we should distribute excess width proportionally
to the width of the cell, not to the preferred increment. Doing the
latter leads to distributing all excess width to just the cells which
demand some increment, even if it's very modest. Moreover, there's code
which partially implements the correct criteria just below the one we
remove here.
Once we've resolved the used flex item width & height, we should allow
percentage flex item sizes to resolve against them instead of forcing
flex items to always treat percentages as auto while doing intrinsic
sizing layout.
Regressed in 8dd489da61.
We do this by piggybacking on FormattingContext helpers instead of
reinventing the wheel in FlexFormattingContext.
This fixes an issue where `min-width: fit-content` (and other
layout-dependent values) were treated as 0 on flex items.
This makes the cookie banners look okay on https://microsoft.com/ :^)
If an inline-block has a percentage height that relies on the auto
height of the containing block, it should always resolve to the
automatic height of the box, regardless of the percentage value. This
change may seem confusing, but it aligns with the behavior of other
engines.
Unlike all other primitives elliptical arcs are non-trivial to
manipulate, it's tricky to correctly apply a Gfx::AffineTransform to
them. Prior to this change, Path::copy_transformed() was still
incorrectly applying transforms such as flips and skews to arcs.
This patch very closely approximates arcs with cubic beziers (I can not
visually spot any differences), which can then be easily and correctly
transformed in all cases.
Most of the maths here was taken from:
https://mortoray.com/rendering-an-svg-elliptical-arc-as-bezier-curves/
(which came from https://www.joecridge.me/content/pdf/bezier-arcs.pdf,
now a dead link).
There are two parts to this fix:
- First, StyleProperties::transformations() would previously omit calc()
values entirely when returning the list of transformations. This was
very confusing to StackingContext which then tried to index into the
list based on faulty assumptions. Fix this by emitting calc values.
- Second, StackingContext::get_transformation_matrix() now always calls
resolve() on length-percentages. This takes care of actually resolving
calc() values. If no reference value for percentages is provided, we
default to 0px.
This stops LibWeb from asserting on websites with calc() in transform
values, such as https://qt.io/ :^)
This change implements following paragraph from placement algorithm in
the spec:
"If the largest column span among all the items without a definite
column position is larger than the width of the implicit grid, add
columns to the end of the implicit grid to accommodate that column
span."
There were places in the grid implementation code with copies of this
text, but those were completely unrelated to the code where they were
being pasted so I removed them.
Max width shouldn't be tied to min width, commit d33b99d went too far
and made them the same when the table-root had a specified percentage
width.
Fixes#19940.
Make sure the insets and margins calculated according to the spec are
not later ignored and ad-hoc recomputed in
layout_absolutely_positioned_element.
Use the static position calculation in a couple of places where the
spec (and comment) was indicating it should be used.
Fixes#19362
The tests still pass, but opening the files in Ladybird and Safari or
Firefox shows clearly where the layouting in Ladybird is incorrect
for some absolute positioned elements. The previous 1px border was
subtly hiding some issues.
When the containing block has an indefinite width, any descendants with
a percentage size should resolve that against 0, not infinity.
Fixes an assertion failure when loading https://www.gnu.org/
When sizing under a max-content constraint, we allow flex lines to have
an infinite amount of "remaining space", but we shouldn't let infinity
leak into the geometry of items. So treat it as zero in arithmetic.
This fixes an issue where inline SVGs with natural aspect ratio (from
viewBox) but no natural width or height could get an infinite size as
flex items.
All of the following properties in the font shorthand can be `normal`:
- font-style
- font-variant
- font-weight
- font-stretch
This means that we must allow up to four consecutive `normal` at the
start of a font shorthand value.
Anonymous wrapper boxes inherit style from their layout tree parent,
and since style data is per-layout-node, we have to manually sync them
from parent to anonymous children when something changes.
This is not very elegant or efficient, so I've left a FIXME about
solving it in a nicer way.
This fixes horizontal dog alignment on https://waffles.dog/ :^)
As it turns out, Layout::TreeBuilder never managed to wrap text within
table boxes in anonymous wrapper boxes, since it relied on checking
text_for_rendering(), and that was never initialized during that early
stage of tree building.
This patch fixes the issue by making text_for_rendering() compute the
(potentially collapsed) text lazily when called.
Note that the test included with this patch is still totally wrong,
but that is now a TFC problem rather than a TreeBuilder problem. :^)
Computing the table width algorithm bifurcates based on whether
table-root width is auto. We only adjust the used table width based on
cell percentage widths on the auto branch, thus the same check is needed
when we initialize cell widths.
