[css-transitions-2] Support transition-behavior property
Categories
(Core :: CSS Transitions and Animations, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox125 | --- | fixed |
People
(Reporter: mozilla-apprentice, Assigned: boris)
References
(Depends on 1 open bug, Blocks 4 open bugs, )
Details
(Keywords: dev-doc-complete)
Attachments
(6 files, 9 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
A resolution was made for csswg-drafts/#4441.
[css-transitions-2] Start transitions on discrete animation types
- RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition
Comment 1•2 years ago
•
|
||
Clarifying slightly:
Up until this point, the spec has said the following (in section 3 "Starting of transitions"):
When comparing the before-change style and after-change style for a given property, the property values are transitionable if they have an animation type that is neither
not animatable
nordiscrete
.
Today's resolution made this change:
- we're removing the "...nor discrete" qualifier. So: now properties with animation-type "disrete" are considered to be transitionable
- they transition when their easing function gets past 50%, essentially (this falls implicitly out of the animation spec and how it interacts with transitions)
- discretely-transitionable properties are not included in
transition-property: all
. If you want to transition them, you have to explicitly list them by name in thetransition-property
list.
(There's a proposal to include another catch-all keyword for all such properties so that you could do something like transition-property: all, discrete
, but we didn't resolve on that today.)
Comment 2•2 years ago
|
||
+CC :boris and :hiro -- this seems like it'll be needed for interop2023, if either of you have cycles to pick up this transitions spec change. (Looks like the Chrome equivalent was https://bugs.chromium.org/p/chromium/issues/detail?id=1399631 which landed recently.)
(See bug 1822203 for some interop2023-relevant WPT tests that currently depend on this change.)
Comment 3•2 years ago
|
||
It should be straight-forward, just removing this condition would work? I may be wrong since my memory about animation is quite stale.
Assignee | ||
Comment 4•2 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #2)
+CC :boris and :hiro -- this seems like it'll be needed for interop2023, if either of you have cycles to pick up this transitions spec change. (Looks like the Chrome equivalent was https://bugs.chromium.org/p/chromium/issues/detail?id=1399631 which landed recently.)
(See bug 1822203 for some interop2023-relevant WPT tests that currently depend on this change.)
Yes. I also noticed there are some wpt failures of motion path because of this bug.
Assignee | ||
Comment 5•2 years ago
•
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
It should be straight-forward, just removing this condition would work? I may be wrong since my memory about animation is quite stale.
I will try it once the wpt gets merged. I suspect we may have to do other changes but I can take a look at this after the web-platform tests are ready in our repo.
Assignee | ||
Comment 6•2 years ago
|
||
Waiting for wpt sync.
Comment 7•2 years ago
|
||
We need to make sure "all" doesn't transition discrete properties, but hopefully that's covered.
Assignee | ||
Comment 8•2 years ago
|
||
(In reply to Brian Birtles (:birtles) from comment #7)
We need to make sure "all" doesn't transition discrete properties, but hopefully that's covered.
Right. We may have to update the logic here as well, to accept discrete animation type only for longhand properties in the list.
Comment 9•2 years ago
|
||
(putting Boris in Assigned field to reflect reality, since I think he's working on this now or in the near term. Thanks Boris! Feel free to unassign if I'm misunderstanding. :) )
Assignee | ||
Comment 10•2 years ago
|
||
This refactoring is needed because we cannot make decision to cancel the
transitions during the loop, before finishing the check of all transition
properties.
The next patch will start transitions on discrete animation types, only
if we specify the specific transition properties (i.e. longhand and shorthand
properties). We don't start transition on discrete animations if this
transition is from all
property (i.e. transition-property: all).
Updated•2 years ago
|
Assignee | ||
Comment 11•2 years ago
|
||
The only difference is the usage of nsCSSProps::IsEnabled()
for all
keyword when handling the cancellation of existing transitions.
However, this is a kind of preference check so it shouldn't break the
consistency.
Updated•2 years ago
|
Assignee | ||
Comment 12•2 years ago
|
||
Just try to make it easier to read the code.
Assignee | ||
Comment 13•2 years ago
|
||
So we don't have to go through transition-property twice.
Assignee | ||
Comment 14•2 years ago
|
||
We still disable the global preference, but only enable it for WPT.
So basically, we just drop the unexpected pass from the meta. The
only exception is css/css-transitions/CSSTransition-canceling.tentative.html.
We should use all
in the test so we cancel the transition when using a
non-interpolatable property value.
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
For Gecko internal layout tests, there are a lot of change in
test_transitions_per_property.html:
- Add a global array to represent the properties with discrete
animation types, so we skip these properties in general. - Update the expectation when the test fall back to discrete.
- Skip tests of Motion path because we have enough tests in WPT.
For Gecko internal animation tests, we use all
keyword in
test_animation_observers_sync.html to make sure we still cancel the
transition with non-interpolated values.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 16•2 years ago
|
||
We got timeout in
- browser/components/customizableui/test/browser_947914_button_history.js
- browser/components/places/tests/browser/browser_toolbar_library_open_recent.js
- browser/modules/test/browser/browser_UsageTelemetry_interaction.js
I suspect these interaction tests expect there is no transition for
some cases. For example, browser_947914_button_history.js hangs when
calling await browserLoaded
because it seems like the test doesn't click
the selected item. Not sure what happens exactly, so for now I just disable
the pref for them and we have to fix them later.
Assignee | ||
Updated•1 years ago
|
Updated•1 years ago
|
Updated•1 years ago
|
Comment 17•1 years ago
|
||
Note: as noted on https://github.com/web-platform-tests/wpt/issues/39871#issuecomment-1536898732, it seems the spec's relatively-simple "transition:all expands-to-all-non-discrete-properties" behavior is not necessarily web-compatible.
A Chromium engineer linked to one regression that they ran into there:, where it's problematic for "transition:all" to cause discrete transitions to play for a change from top:auto
to top:50%
: https://bugs.chromium.org/p/chromium/issues/detail?id=1439802
(They also mentioned "It may turn out that we can't ship this new discrete transition behavior at all, but I am still working on figuring that out.")
Comment 18•1 years ago
|
||
Independent of how code-review shakes out here, it'd be probably worth hold off on landing this for at least a week or so. A chromium engineer working on this feature (@josepharhar) is doing a bit of research with their implementation this week[1], which might result in an assessment that this behavior is "for sure unshippable" (at which point presumably there'd be a csswg discussion / spec update).
(That would be quite unfortunate after all the work you've put into implementing it and updating test-expectations etc. :-/ Sorry about that if that turns out to be the case. Though I suppose it's nice that the Chromium folks are discovering the possible webcompat breakage before we've landed rather than later in our release process.)
[1] https://github.com/web-platform-tests/wpt/issues/39871#issuecomment-1538653293
Assignee | ||
Comment 19•1 years ago
•
|
||
I will move part 1 to part 3 to a separate bug (Bug 1831981) because these three patches don't change the behavior and just improve the readability. So we can land them first.
Comment 20•1 years ago
|
||
Comment on attachment 9328636 [details]
Bug 1805727 - Part 1: Share code for expanding all keyword and shorthands when iterating transition-property list.
Revision D175533 was moved to bug 1831981. Setting attachment 9328636 [details] to obsolete.
Assignee | ||
Updated•1 years ago
|
Comment 21•1 years ago
|
||
Comment on attachment 9327607 [details]
Bug 1805727 - Part 2: Move the cancellation of transitions into a separate function.
Revision D174985 was moved to bug 1831981. Setting attachment 9327607 [details] to obsolete.
Comment 22•1 years ago
|
||
Comment on attachment 9328637 [details]
Bug 1805727 - Part 3: Make the creation of a transition be a separate function.
Revision D175534 was moved to bug 1831981. Setting attachment 9328637 [details] to obsolete.
Comment 23•1 year ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #17)
A Chromium engineer [...] also mentioned "It may turn out that we can't ship this new discrete transition behavior at all, but I am still working on figuring that out.")
Update: there's now a spec issue on putting this new behavior behind a new syntax, so that it can become opt-in instead of changing the default behavior. That's https://github.com/w3c/csswg-drafts/issues/8857
(Not sure what that means for all the interop2023-relevant WPTs that were changed to expect this behavior, but I suspect those should all be reverted to test the old currently-shipping-in-all-browsers behavior, and there'll be some new test to specifically test the new behavior.)
Assignee | ||
Comment 24•1 year ago
|
||
So we can reuse this bug to implement https://github.com/w3c/csswg-drafts/issues/8857#issuecomment-1581650809.
Comment hidden (obsolete) |
Assignee | ||
Comment 26•1 year ago
|
||
The spec has been updated (https://drafts.csswg.org/css-transitions-2/#transition-behavior-property).
Need to support this new CSS property, so we have the ability to start the CSS transitions for property or values that are animatable discretely:
<transition-behavior-value> = normal | allow-discrete
Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Assignee | ||
Comment 27•9 months ago
|
||
Add transition-behavior longhand property. This doesn't include layout
animation support.
Assignee | ||
Comment 28•9 months ago
|
||
Per spec, we put transition-behavior
last in transition
.
https://drafts.csswg.org/css-transitions-2/#transition-shorthand-property
Assignee | ||
Comment 29•9 months ago
|
||
Per https://github.com/web-platform-tests/wpt/issues/43574, we should
follow the shortest serialization principle for transition
shorthand.
Updated•9 months ago
|
Updated•9 months ago
|
Comment 30•9 months ago
|
||
Comment on attachment 9377849 [details]
Bug 1805727 - Part 3: Follow shortest serialization principle for transition shorthand.
Revision D200410 was moved to bug 1878758. Setting attachment 9377849 [details] to obsolete.
Assignee | ||
Comment 31•8 months ago
|
||
Its name doesn't match the current spec because all
is not a special case for
transition-behavior
. (For more specifically, it uses the obsolete spec
definition.)
Assignee | ||
Comment 32•8 months ago
|
||
The implementation is straight-forward. We have to check
if transition-behavior
is allow-discrete
when trying to create a new
transition and when checking if we have to cancel a running transition.
Also, the test case is out-of-date, so I tweak it a little bit and add
more general test cases for transtiion-behavior.
Assignee | ||
Comment 33•8 months ago
|
||
When transition-behavior is allow-discrete, the animation values are
transitionable even if they are not interpoltable, given that the
animation type of the CSS property is by computed value.
Comment 34•8 months ago
|
||
Comment 36•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/8ffd5fe0ee69
https://hg.mozilla.org/mozilla-central/rev/ea25a67b45f8
https://hg.mozilla.org/mozilla-central/rev/6b9c12c81a43
https://hg.mozilla.org/mozilla-central/rev/9c80651bc341
https://hg.mozilla.org/mozilla-central/rev/6203d25d0748
Assignee | ||
Comment 39•8 months ago
|
||
Proposal to add tests into interop meta: https://github.com/web-platform-tests/interop/issues/639
Assignee | ||
Comment 40•8 months ago
|
||
Comment 41•8 months ago
|
||
Comment 43•8 months ago
|
||
bugherder |
Comment 44•8 months ago
|
||
A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)
Comment 46•8 months ago
|
||
Is this something we should add to the Fx125 relnotes?
Comment hidden (obsolete) |
Assignee | ||
Comment 48•8 months ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: This is a new feature defined in CSS Transitions Module Level 2. We support transition-behavior property so the users can determine whether we generate the CSS transitions for properties with the discrete animation type, or for properties whose animation values fall back to discrete animations (i.e. not interpolatable but discretely animatable).
[Affects Firefox for Android]: Yes. This affects all platforms.
[Suggested wording]: Support transition-behavior property on Nightly
[Links (documentation, blog post, etc)]: https://www.w3.org/TR/css-transitions-2/#transition-behavior-property
Note: This is enabled on Nightly only for now, and we would like to wait for at least 3 cycles.
Comment 49•8 months ago
|
||
Added to the Nightly relnotes, thanks.
Starting with Firefox 125, the
transition-behavior
CSS property is now supported in Nightly builds.
Updated•6 months ago
|
Comment 50•6 months ago
|
||
MDN docs changes can be tracked in the following GitHub issue: https://github.com/mdn/content/issues/32664
Comment 51•4 months ago
|
||
Removing the nightly+ relnote flag, this will ride the train with Fx129 (Bug 1901645)
Description
•