This change is currently entirely undetectable because of what the
added FIXME talks about. Currently, the HTML element's overflow is
always set to visible in both axes, so it getting set to "clip" in
the imported test ends up not mattering at all.
This commit includes two interdependent changes that must be applied
together:
- Treat `fit-content()` tracks as having an intrinsic min sizing
function when the limit resolves to zero.
- When clamping growth limit to fit-content limit, use `max(base_size,
fit_content_limit)` instead of just `fit_content_limit` to preserve
intrinsic sizing contributions.
These changes are coupled because the first change causes
`fit-content(0)` tracks to participate in intrinsic sizing, while the
second ensures the base size from that sizing is not discarded during
clamping.
Some subtests changed in response to this CSSWG resolution:
https://github.com/w3c/csswg-drafts/issues/11494#issuecomment-2675800489
Basically, `border-style: none` now affects the used value of
`border-width`, not the computed value. (And the same for `outline`
properties.)
This affects way more tests than I expected because
interpolation-testcommon.js now adds tests for composition.
Previously we would only update these if:
a) We had a cascaded value for `transition-property`
b) The source of that cascaded value had changed since we last
registered transitions
This meant that there were a lot of changes we didn't apply:
- Changes exclusively to properties other than `transition-property`
(e.g. `transition-duration`, `transition-behavior`, etc)
- Removing the `transition-property` property
- Updating the `transition-property` property in a way that didn't
change it's source (e.g. setting it within inline-style)
Unfortunately this does mean that we now register transitions for all
properties on most elements since "all" is the initial value for
"transition-property" which isn't great for performance, but that can be
looked at in later commits.
If either of the two transform functions during interpolation is a 3D
function, both of them get coerced to a 3D function before deciding what
to do next. However, we only supported converting 2D functions to 3D if
they had a 2D primitive they could be converted to first.
Change our behavior to default to converting to matrix3d() if there is
no explicit conversion path. Fixes a crash in
`css/css-transforms/animation/transform-interpolation-004.html`.
We had a partial implementation of transformation function interpolation
that did not support numerical interpolation of simple functions (e.g.
`scale(0)` -> `scale(1)`). This refactors the interpolation to follow
the spec more closely.
Gains us 267 WPT subtest passes in `css/css-transforms`.
Fixes#6774.
In several content calculation methods in FormattingContext, we assumed
that if create_independent_formatting_context_if_needed() fails the
input Layout::Box is a BlockContainer; however, the web platform test
css/css-pseudo/parsing/marker-supported-properties-in-animation.html is
one scenario where the input is a Layout::ListItemMarkerBox instead and
there is no FormattingContext supported for it yet.
Doing trigonometric calculations with floating point numbers can
introduce small inaccuracies. This meant that we would sometimes
incorrectly generate a 3d rather than 2d matrix for the resolved value
of `transform`.
Gains us 3 WPT tests.
