The specification isn't explicit about it, but the contribution we
compute should be distributed to all columns, not just the first one.
The first reason for it is symmetry, it doesn't make sense for the
increased width of the spanning column to only affect the first column
in the span.
The second reason is the formula for the cell contribution, which is
weighted by the non-spanning width of the cell relative to the total
width of the columns in the same row. This only covers a fraction of the
gap, in order to fully cover it we have to add it to all columns in the
span. For this to be exactly the case when the columns don't all have
the same width, we'd have to add additional weighting based on the width
ratios, but given that the specification doesn't suggest it at all we'll
leave it out for now.
Calculate a "preferred aspect ratio" based on the value of
`aspect-ratio` and the presence of a natural aspect ratio, and use that
in layout.
This is by no means complete or perfect, but we do now apply the given
aspect-ratio to things.
The spec is a bit vague, just saying to calculate sizes for
aspect-ratio'ed boxes the same as you would for replaced elements. My
naive solution here is to find everywhere we were checking for a
ReplacedBox, and then also accept a regular Box with a preferred aspect
ratio. This gets us pretty far. :^)
https://www.w3.org/TR/css-sizing-4/#aspect-ratio-minimum is not at all
implemented.
Having this here instead of in ReplacedBox means we can access it when
figuring out what the "preferred aspect ratio" is.
There's some inconsistency between specs about what this is called, but
they're moving towards referring to this as "natural width/height/
aspect-ratio", so let's copy that terminology.
The implementation of painting for SVG text follows the same pattern
as the implementation of painting for SVG geometries. However, instead
of reusing the existing PaintableWithLines to draw text, a new class
called SVGTextPaintable is introduced. because everything that is
painted inside an SVG is expected to inherit from SVGGraphicsPaintable.
Therefore reusing the text painting from regular text nodes would
require significant refactoring.
We were incorrectly returning a "specified size suggestion" for flex
items with a definite main size where that main size was also automatic.
This led to us incorrectly choosing 0 as the automatic minimum size for
that flex item, instead of its min-content size.
Adds a second pass to resolve percentage paddings and margins of grid
items after track sizes are known. If resolving percentage paddings
or margins affects tracks sizes then second pass to re-resolve track
sizes might also be needed but I cannot come up with an example to
reproduce that so we can leave it to improve in the future :)
This fixes the issue when functions that distribute base_size
or growth_limit to tracks only considered *affected* spanned tracks
while calculating left extra that is available for distribution while
indeed it should be just *all* spanned track by specific item that
extra space size.
This changes grid items position storage type from unsigned to signed
integer so it can represent negative offsets and also updates placement
for grid items with specified column to correctly handle negative
offsets.
This fixes an issue where images with padding and/or border did not have
their size adjusted for `border-box`, thereby becoming larger than
intended by the author.
If a box has a negative margin-left, it may have a negative effective
offset within its parent BFC root coordinate system.
We can account for this when calculating the amount of left-side float
intrusion by flooring the X offset at 0.
The spec for the `<use>` element requires a shadow tree for the
rendered content, so we need to be able to escape shadow trees when
rendering svg content.
These markers are rendered as equilateral triangles pointing right and
down respectively. As we currently don't implement writing-mode the
closed marker does not respect it.
If a flex item's main size is a CSS calc() value that resolves to a
length and contains a percentage, we can only resolve it when we have
the corresponding reference size for the containing block.
Stacking contexts are sorted after building a tree of them. They are
sorted by z-index first, DOM tree order second.
Sorting was previously *very* slow on pages with many stacking contexts.
That was because the sort() function used Node::is_before() in the
quick_sort comparator to see if one StackingContext was before another.
is_before() does tree traversal and can take quite a long time per call.
This patch avoids all that by letting StackingContext know its index
among all StackingContexts within the same document in tree order.
There's a noticeable snappiness increase on the CSS-FLEXBOX-1 spec page,
for instance. :^)
Previously, we would always respect the `text-align` property, even if
the text being aligned was too long for its line box and would be
clipped. This led to seeing the clipped middle/end of strings when we
should instead always see the beginning of the text.
Having one StyleValue for `<number>` and `<integer>` is making user code
more complicated than it needs to be. We know based on the property
being parsed, whether it wants a `<number>` or an `<integer>`, so we
can use separate StyleValue types for these.
If the flex container is being sized under a max-content main size
constraint, there is effectively infinite space available for flex
items. Thus, flex lines should be allowed to be infinitely long.
This is a little awkward, because the spec doesn't mention specifics
about how to resolve flexible lengths during intrninsic sizing.
I've marked the spec deviations with big "AD-HOC" comments.
Instead of just measuring the layout viewport, we now measure overflow
in every box that is a scroll container.
This has the side effect of no longer creating paintables for layout
boxes that didn't participate in layout. (For example, empty/anonymous
boxes that were ignored by flex itemization.)
Such boxes are now marked as "(not painted)" in the layout tree dumps,
as they have no paintable to dump geometry from.
We already clamp these values to zero, so it's actually pretty harmless
when this happens. If someone wants to investigate these issues deeper
and see if they can be fixed earlier in the layout pipeline, they can
enable the spam locally.
These are only used during layout, and always within formatting context
code, so we might as well put them in FormattingContext and avoid having
to pass the LayoutState around all the time.
At one point in the past, we had some functions that were called across
different formatting context types, which necessitated making them
static and taking the LayoutState as a parameter.
In all cases, those functions were used to do incorrect hacks, all of
which we've replaced with more correct solutions. :^)
Separating the paths for replaced and non-replaced floating boxes lost
the logic for margin, padding and border which was done by
compute_width_for_floating_box. Set them the same way as we do for
block-level replaced elements, per the specification.
Solves conflict in layout tree "type system" when elements <label> (or
<button>) can't have `display: table` because Box can't be
Layout::Label (or Layout::ButtonBox) and Layout::TableBox at the same
time.
From spec https://drafts.csswg.org/css-grid/#grid-items:
"Each in-flow child of a grid container becomes a grid item, and each
child text sequence is wrapped in an anonymous block container grid
item."
Fixes the problem that text sequences inside grid containers are
ignored and not displayed.
Fixes the bug that currently we always consider tracks with percentage
size as ones with "fixed" length even when available size is not
definite. With this change tracks with percentage size when available
size is not definite will be considered as "intrinsic" sized.
We were not taking reverse flex directions into account when choosing
the initial offset for flex item placement if justify-content were
either space-around or space-between.
Specifically, stop letting NumericStyleValues holding `0` from
pretending to hold a Length. The parser is now smart enough that we
don't have to do this. :^)
Only NumericStyleValue holds integers.
I'm not sure our current distinction between NumericStyleValue holding
an integer or non-integer is useful given it always returns a float.
:thonk:
