This fix resolves issue where calculating the min size of a block could
result in incorrect value if width of the block's children was
compensated by margins to fit into container width (which is equal to 0
during min size calculation).
When we determine that a size is definite because it can be resolved now
without performing layout, we also need to account for the box-sizing
property.
This lets us remove a hack from flex layout where box-sizing:border-box
was manually undone at one point in the layout algorithm.
These functions no longer do anything interesting and just forward to
content_width/content_height. Let's make the callers use those directly
instead and remove this indirection layer.
This commit implements following missing steps in table layout:
- Calculate final table height
- Resolve percentage height of cells and rows using final table height
- Distribute avilable height to table rows
If total max columns width (grid_max) is zero then available width
should be divided equally between columns. Previously there was
division by zero: `column.max_width / grid_max`.
This bit is mostly ad-hoc for now. This simply turns fill: url(#grad1)
into document().get_element_by_id('grad1') then resolves the gradient.
This seems to do the trick for most use cases, but this is not
attempting to follow the spec yet to keep things simple.
Previously, the minimum height of a table row was calculated based
on the automatic height of the cells inner layout. This change makes
computed height of a cell boxes also be considered if it has definite
value.
For example, it's possible to access Node::computed_values() on a node
that neither has style nor a parent with style. This ultimately results
in a null pointer dereference when we return parent()->computed_values()
as a fallback. This can be a little tricky to track down due to these
functions being inlined, so add an explicit verification.
If there is a remaining margin-bottom in margin collapsing state
tracker after laying out all boxes in the current BFC, it must be
assigned to the last in-flow child since margin collapsing cannot
occur across a formatting context boundary.
The current issue where margin-bottom may be counted twice due to
"collapse through" margins in the last in-flow child box is addressed
with this fix by excluding such boxes during the search for a box to
assign the remaining margin.
Test case coming with this fix has a layout bug with incorrectly
computed line height.
This fixes a bug that was seen when a combination of the grid having
been floated with `float: left` and a `minmax()` column size were used.
The issue was that a grid track size should be considered intrinsically
sized if both the min and max sizes are intrinsic, not just one of them.
It returns a PaintableBox (a PaintableWithLines, to be specific), not a
'PaintBox'. paintable_box() without the cast is already available
through BlockContainer's Box base class, we don't need to shadow it.
Now that LengthStyleValue never contains `auto`, IdentifierStyleValue is
the only type that can hold an identifier. This lets us remove a couple
of virtual methods from StyleValue.
I've kept `has_auto()` and `to_identifier()` for convenience, but they
are now simple non-virtual methods.
This is far from perfect, but let's at least make an attempt at laying
out <svg> when encountering it inside another <svg>.
This makes https://awesomekling.substack.com actually load and render
instead of asserting. :^)
Although the spec doesn't mention it, if a flex item has box-sizing:
border-box, and the specified size suggestion is a definite size, we
have to subtract the borders and padding from the size before using it.
This fixes an issue seen in "This Week in Ladybird #4" where the
screenshots ended up in one long vertical stack instead of paired up
2 by 2.
This attribute is used to define how the viewBox should be scaled.
Previously the behaviour implemented was that of "xMidYMid meet", now
all of them work (expect none :P).
With this the Discord login backend is now correctly scaled/positioned.
This also brings our SVG code a little closer to the spec! With spec
comments and all :^)
(Minor non-visible update to layout tests)
When sizing a flex container with flex-direction:column under a
max-content height constraint, we were incorrectly truncating the
infinite available height to 0 when collecting flex items into lines.
This caused us to put every flex item in its own flex line, which is the
complete opposite of what we want during max-content intrinsic sizing,
as the layout would grow wide but not tall.
This isn't actually part of CSS-FLEXBOX-1, but all major engines honor
these properties in flex layout, and it's widely used on the web.
There's a bug open against the flexbox spec where fantasai says the
algorithm will be updated in CSS-FLEXBOX-2:
https://github.com/w3c/csswg-drafts/issues/2336
I've added comments to all the places where we adjust calculations for
gaps with "CSS-FLEXBOX-2" so we can find them easily. When that spec
becomes available, we can add proper spec links.
Log a FIXME on the debug log, along with a layout tree dump of the box
that we didn't expect to see. This will be annoying (until fixed),
but far less so than crashing the browser.
This also combines the viewbox mapping into the same transform and
reuses some code by using Path::copy_transformed() rather than manually
mapping each segment of the path.
Previously, if you had an SVG with a viewbox and a definite width
and height, then all SVGGeometryBox boxes within that SVG would
have a width and height set to the size of the parent SVG.
This broke hit testing for SVG paths, and didn't make much sense.
It seems like the SVG sizing hack was patching over the incorrect
logic in viewbox_scaling() and the incorrect path sizing (which was
never reached).
Before this change the view box scaling was:
element_dimension / viewbox_dimension
Which only seemed to work because of the SVG sizing hack that made
all paths the size of the containing SVG.
After this change SVGGeometryBoxes are (in most cases) sized correctly
based on their bounding boxes, which allows hit testing to function,
and the view box scaling is updated now to:
containing_SVG_dimension / viewbox_dimension
Which works with one less hack :^)
This now also handles centering the viewbox within the parent SVG
element and applying any tranforms to the bounding box. This still
a bit ad-hoc, but much more closely matches other browsers now.
Grid and flex containers have their own rules for abspos items, so we
shouldn't try to be clever and put them in the "current" anonymous
wrapper block. That behavior is primarily for the benefit of block &
inline layout.
When calculating the intrinsic width of a block-level box, we now ignore
the preferred width entirely, and not just when the preferred width
should be treated as auto.
The condition for this was both confused and wrong, as it looked at the
available width around the box, but didn't check for a width constraint
on the box itself.
Just because the available width has an intrinsic sizing constraint
doesn't mean that the box is undergoing intrinsic sizing. It could also
be the box's containing block!
This parses the new background-position-x/y longhands and properly
hooks up them up. This requires converting PositionStyleValue to
just contain two EdgeStyleValues so that it can be easily expanded
into the longhands.
In situations where we need a width to calculate the intrinsic height of
a flex item, we use the fit-content width as a stand-in. However, we
also need to clamp it to any min-width and max-width properties present.
In `flex-direction: column` layouts, a flex item's intrinsic height may
depend on its width, but the width is calculated *after* the intrinsic
height is required.
Unfortunately, the specification doesn't tell us exactly what to do here
(missing inputs to intrinsic sizing is a common problem) so we take the
solution that flexbox applies in 9.2.3.C and apply it to all intrinsic
height calculations within FlexFormattingContext: if the used width of
an item is not yet known when its intrinsic height is requested, we
substitute the fit-content width instead.
Note that while this is technically ad-hoc, it's basically extrapolating
the spec's suggestion in one specific case and using it in all cases.
When calculating the intrinsic width of a box, we now make its content
width & height indefinite before entering the intrinsic sizing layout.
This ensures that any geometry assigned to the box by its parent
formatting context is ignored.
For intrinsic heights, we only make the content height indefinite.
This is because used content width is a valid (but optional) input
to intrinsic height calculation.
