Skip to content

test_no_interpolation tests don't have the right expectations for transitionable properties that have value-pairs that interpolate discretely #39871

@dholbert

Description

@dholbert

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".

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions