| Age | Commit message (Collapse) | Author |
|---|
|
We were resolving percentage values against the containing block size in
the wrong axis.
|
|
While it's possible to getComputedStyle() on an unconnected element,
the resulting object is not supposed to have any values, since we can't
resolve style without a document root anyway.
This fixes a crash on https://bandcamp.com
|
|
If there are min or max size constraints in the cross axis for a flex
item that has a desired aspect ratio, we may need to adjust the main
size *after* applying the cross size constraints.
All the steps to achieving this aren't mentioned in the spec, but it
seems that all other browsers behave this way, so we should too.
|
|
Implements some parts of "Resolve Intrinsic Track Sizes" algorithm
from spec to make it more spec compliant.
|
|
Instead of bailing after resolving one violated constraint, we have to
continue down the list of remaining constraints.
We now also call the constraint solver for all replaced elements with
"auto" for both width and height.
Co-authored-by: 0GreenClover0 <clovers02123@gmail.com>
|
|
This change moves the initial offset for justify-content: center to the
opposite side if the flex layout is in the reverse direction.
|
|
1. Stop using -1 to indicate infinity value of growth limit. Just use
INFINITY for that.
2. More complete implementation of "Expand Flexible Tracks" step.
3. Return AvailableSize from get_free_space: spec says that this
function can return indefinite size and it is ok.
|
|
|
|
The file gap.html, which previously had multiple grid tests, has now
been divided into smaller files, each containing only one grid test.
It is going to make it easier to identify what inputs have been
affected by changes in layout code.
|
|
The file template-areas.html, which previously had multiple grid tests,
has now been divided into smaller files, each containing only one grid
test. It is going to make it easier to identify what inputs have been
affected by changes in layout code.
Also this change removes parts of template-areas.html that we can't
layout correctly yet.
|
|
If the parent BFC can come up with a nice stretch-fit width for the flex
container, it will have already done so *before* even entering flex
layout. There's no need to do it again, midway through the flex layout
algorithm.
This wasn't just unnecessary, but we were also doing it incorrectly and
not taking margins into account when calculating the amount of available
space for stretch-fit. This led to oversized flex containers in the
presence of negative margins.
Fixes #18614
|
|
Also do some test changes to test it out :^)
|
|
Width of table wrapper need to be set to to calculate width of table
box inside. Otherwise TFC will set wrong width assuming width of
containing block is 0.
|
|
Fixes #18658
|
|
Although the algorithm for sizing tracks (rows or columns) is defined
once for both dimensions in the specification
(https://www.w3.org/TR/css-grid-2/#algo-track-sizing), we have
implemented it twice separately for sizing rows and columns.
In addition to code duplication, another issue is that these
implementations of the same algorithm have already diverged in some
places, and this divergence is likely to become even worse as our
implementation evolves.
This change unifies code for both dimension into one method that runs
track sizing.
While this change brings a bit of collateral damange (border.html and
minmax.html got changes in layout snaphots) it ultimately brings more
benefits because now we can evolve layout for both rows and colums
without duplicating the code :)
|
|
Reverse the condition to satisfy the spec comment. Probably a typo.
A 3 year old typo! :^)
|
|
`Length::resolved(Node&)` transforms infinite values to "auto".
Following transformations:
Infinite (Length) -> "auto" -> 0 (px)
cause border-box width to be resolved in zero when it should be inf px.
Removing `Length::resolved(Node&)` makes it work right:
Infinite (Length) -> Infinite (px)
Fixes #18649
|
|
If available width (or height) is max-content and width (or height)
value is 100% it should be resolved in infinite px, not 0 px.
Fixes #18639
|
|
https://www.w3.org/TR/CSS22/visuren.html#floats says that when a box
establishes BFC it should not overlap with floats. The way to avoid
overlaps is up to implementor. This change implements avoiding overlap
by narrowing width of a box because it seems like what other engines
do (in the scenarios I tested).
|
|
Fixes #18037.
|
|
When there are floats present inside an IFC, we must coordinate with
the parent BFC to calculate the automatic width of the IFC's block box.
This is because the IFC is not directly aware of floats. Only the BFC
knows enough about them to account for them in automatic sizing.
|
|
In particular, we now blockify layout internal boxes (e.g table parts)
by turning them into `block flow`. This fixes a crash when viewing
our GitHub repo :^)
|
|
Table should not take up more width than is available inside wrapper
after margins are taken in account.
|
|
This solves the issue that previously width table-wrapper containing
block were used in the places were containing block of table-root
should be used.
|
|
This patch does three things:
- Factors out the code that determines whether a box will create a new
formatting context for its children (and which type of context)
- Uses that code to mark all formatting context roots in layout tree
dumps. This makes it much easier to follow along with layout since
you can now see exactly where control is transferred to a new
formatting context.
- Rebaselines all existing layout tests, since the output format has
changed slightly.
|
|
Fixes the problem that width is incorrectly computed in intrinsic
sizing mode when there are blocks that have min-width or max-width
specified.
Actually that is just the fix of a symptom of the larger problem that
Length::to_px() returns 0 when value is auto regardless of available
size.
|
|
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.
|
|
|
|
|
|
Fix table box width calculation to minus horizonal borders from space
available for columns.
|
|
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`.
|
|
|
|
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.
|
|
Fixes the issue that currently we do not consider table rows height
while calculating min row height even if it is definite value.
|
|
When deciding on a box type transformation (blockify/inlinify) for a
pseudo element, we have to use the originating element as a reference
rather than the parent.
(The originating element *is* the parent for its pseudo elements.)
|
|
If a flex item has a preferred cross size of "auto", we should not be
subtracting padding and border in the cross axis when computing the
cross size.
|
|
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.
|
|
This change will prevent CI runners from being stuck trying to run
layout tests on PR that made browser hang.
|
|
This is a tiny bit messy because:
- The spec says we should expand this to `flex: <flex-grow> 1 0`
- All major engines expand it to `flex: <flex-grow> 1 0%`
Spec bug: https://github.com/w3c/csswg-drafts/issues/5742
|
|
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. :^)
|
|
Per CSS-FLEXBOX-1, we should treat percentage values of flex-basis as
'content' if they resolve against an indefinite size of the flex
container.
|
|
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.
|
|
Per SVG2, any coordinate pairs following a moveto command should be
treated as implicit lineto commands with the same absoluteness as the
moveto command.
|
|
This is a cut down version of the example, but it's nice to add a
test to ensure this keeps working.
|
|
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.
|
|
We have to take the cross gap into account when calculating the "sum of
flex line cross sizes" in "Handle 'align-content: stretch'".
|
