Add logic to compute {min, max}-height and use min-height when
calculating table height, per specifications.
Fixes some issues with phylogenetic tree visualizations on Wikipedia.
Before this change we always returned the font's point size as the
x-height which was basically never correct.
We now get it from the OS/2 table (if one with version >= 2 is available
in the file). Otherwise we fall back to using the ascent of the 'x'
glyph. Most fonts appear to have a sufficiently modern OS/2 table.
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.
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 fixes the issue that currently we use "auto" as initial value for
grid-template-column and grid-template-rows although spec says it
should be "none". This makes a lot of difference for these properties
because currently we represent "auto" as a list with one auto-sized
track which means initial value for grid-template-column defines one
"explicit" track while it should define none of them.
This change makes grid-auto-columns/rows be applied to the correct
tracks when initial values is used for grid-template-column/rows.
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.
Now that we have a way to resolve calc() lengths without a layout node,
we can finally support calc() values in font-size.
This wasn't possible before because font-related properties have to be
resolved eagerly in StyleComputer due to font-relative CSS length units
depending on the computed font being known.
Use contains_percentage() that works for calc() values instead of
is_percentage().
This fixes issue when tracks with calc() that has percentages where
considered as "fixed" tracks with resolvable size which led to
incorrectly resolved infinite final track sizes.
This reintroduces bounds-checking for the CSS `<angle>`, `<frequency>`,
`<integer>`, `<length>`, `<number>`, `<percentage>`, `<resolution>`,
and `<time>` types.
I regressed this around 6b8f484114 when
changing how we parsed StyleValues.
This is an improvement from before though, since we now allow the bounds
of a dimension type to have units.
Added a test to make sure we don't regress this again. :^)
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.
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.
This is a hack to emulate the behavior of other engines that use
fixed-point math. By rounding to 3 decimals, we retain a fair amount of
detail, while still allowing overshooting 100% without breaking lines.
This is both gross and slow, but it fixes real sites. Notably, the
popular Bootstrap library uses overshooting percentages in their
12-column grid system.
This hack can be removed when CSSPixels is made a fixed-point type.
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.
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.
Since there are no table-specific boxes anymore it would be nice to
output their types additionally in layout dump so we can tell table
boxes from "regular" boxes.
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.
