-
Notifications
You must be signed in to change notification settings - Fork 3.7k
test_no_interpolation tests don't have the right expectations for transitionable properties that have value-pairs that interpolate discretely #39871
Description
I think there's a test bug (and a Chromium bug) in a bunch of interpolation WPT tests that use test_no_interpolation() with discretely-interpolatable values of a property that is otherwise generally interpolatable.
For example, "caret-color" (which takes colors and hence can generally interpolate) and "offset-rotate" (which takes angles and can generally interpolate), whose interpolation is tested in these tests:
http://wpt.live/css/css-ui/animation/caret-color-interpolation.html
http://wpt.live/css/motion/animation/offset-rotate-interpolation.html
General issue / tl:dr: right now, these^ tests expect transition:all to magically include or exclude these properties depending on whether or not the particular begin/end values happen to be discretely vs. smoothly interpolatable. And I don't think that matches the csswg resolution or spec edit -- the spec talks about the property as a whole being included in transition:all depending on whether the property as a whole has a discrete animation type.
Quoting some relevant bits of the test expectations (from running them on wpt.live):
CSS Transitions: property <caret-color> from [auto] to [green] at (0.3) should be [auto]
CSS Transitions with transition: all: property <caret-color> from [auto] to [green] at (0.3) should be [green]
CSS Transitions: property <offset-rotate> from [6rad] to [auto] at (0.3) should be [6rad]
CSS Transitions with transition: all: property <offset-rotate> from [6rad] to [auto] at (0.3) should be [auto]
For a given pair of values, the tests are expecting a discrete 50% flip for transition: <property name> BUT they're expecting an immediate value-change (no transition) for transition: all. I don't think that matches the spec.
Spec reference:
https://drafts.csswg.org/css-transitions-2/#transition-property-property
"the all keyword continues to expand only to all transitionable properties whose animation type is not discrete."
In this case, the property's animation type is not discrete[1], so it should be included in transition:all. (It does have some keyword values like auto that aren't transitionable, but the value as a whole still has a non-discrete Animation Type.
@fantasai, @dbaron, am I understanding this spec text (from w3c/csswg-drafts#8520 ) correctly? Do we need to fix the tests, or is the spec missing some nuance?
(Note that Chromium passes these tests which I think means Chromium has a bug. Firefox starts failing the above-quoted transition: all subtests with our patch to add the 50% flip, in https://bugzilla.mozilla.org/show_bug.cgi?id=1805727 -- but as I understand it, our test-failures are actually what the spec requires.)
[1] e.g. https://drafts.csswg.org/css-ui-3/#caret-color has "Animation type: by computed value" (not "discrete"). Note that "by computed value" is defined such that certain values "combine as discrete" but the property's animation type is still "by computed value".