Intent to Ship: Display and content-visibility animations

[Joey Arhar]

Contact emails

fla...@chromium.org, jar...@chromium.org

Explainer

https://github.com/w3c/csswg-drafts/issues/6429#issuecomment-1318933547

Specification

https://drafts.csswg.org/css-display-4/#display-animation

Summary

Support specifying display and content-visibility in animations. This support allows for developers to create exit animations after which the element automatically becomes display: none or content-visibility: hidden without needing to write any javascript to handle that switch after the animation is finished. This allows exit animations for elements to be added purely in CSS.

Blink component

Blink>Animation

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Developers may have display specified in existing animations which would start being included in their animation after this change.

Gecko: No signal

WebKit: No signal

Web developers: Positive (https://front-end.social/@mia/109433817951030826)

Other signals:

Ergonomics

This will be used in tandem with popover/dialog elements and the CSSTransitionDiscrete feature. Usage of this feature will not make it hard for chrome to maintain good performance.

Activation

It will not be challenging for developers to use this feature immediately.

Security

This doesn't extend developer capabilities beyond styles the developer could set via existing CSS or scripts.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

This is not high risk for WebView, but is controlled by a base::Feature anyway.

Debuggability

This feature extends the capabilities of existing css animations, css transitions and web animations and will show amongst other developer animations.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

CSSDisplayAnimation

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1395394

Measurement

This feature does not have any UseCounters.

Availability expectation

I'm not sure when this will be implemented in safari and firefox. I don't think that they have started implementing this yet, but we only very recently got this resolved in CSSWG.

Adoption expectation

This will be the best practice for animating the entry and exit if dialogs and popovers immediately.

Adoption plan

I don't have an adoption plan.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

This feature does not depend on anything outside of chromium.

Sample links

https://output.jsbin.com/buquher

Estimated milestones

M114

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This change has been specced and I don't think any more changes to the spec will happen.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5154958272364544

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJh39TMCg_NwX3apO7K2t%3DauPVKXWwF9B2RHbkE6yfjCNc8a1w%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Joey Arhar]

TAG review: https://github.com/w3ctag/design-reviews/issues/824

WebKit standards position: https://github.com/WebKit/standards-positions/issues/147

Mozilla standards position: https://github.com/mozilla/standards-positions/issues/762

[Yoav Weiss]

How do we expect developers to use the feature before it is ubiquitously available?

Do we expect them to perform feature detection and compensate for it in JS? Something else? What would that look like?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2BfQHkpoG-cSUF%3DJOTvua7CjX8euRjUjD6DGrm-TJo%3DdQ%40mail.gmail.com.

[Joey Arhar]

> How do we expect developers to use the feature before it is ubiquitously available?
> Do we expect them to perform feature detection and compensate for it in JS? Something else? What would that look like?

This and the other popover/dialog inspired animation features are a progressive enhancement. They are hard to polyfill and we don't expect developers to feature detect and compensate. If they choose to use these features before they are implemented in other browsers, then the animations won't happen but popovers and dialogs (the intended use cases) will still work.

[slightlyoff via Chromestatus]

LGTM1 with the note that TAG reviews should be filed at I2P-time.

[tkent via Chromestatus]

LGTM2. It's a small addition to existing features, and would have very small risks.

[Yoav Weiss]

Thoughts on Emilio's question on https://github.com/mozilla/standards-positions/issues/762#issuecomment-1483059117 RE spec text and avoiding circularity?

On Fri, Mar 24, 2023 at 6:10 AM tkent via Chromestatus <admin...@cr-status.appspotmail.com> wrote:

LGTM2. It's a small addition to existing features, and would have very small risks.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000ca69eb05f79e681a%40google.com.

[Joey Arhar]

> Thoughts on Emilio's question on https://github.com/mozilla/standards-positions/issues/762#issuecomment-1483059117 RE spec text and avoiding circularity?

This is about deciding how to implement the behavior when display:none is specified in a keyframes rule in a way which makes it hard or impossible to extend not-none rules through the whole animation, which is either going to be converting it to display:revert or allowing display:none without canceling the animation. This is not the intended use case of this feature and I don't think it will happen often, so I don't think it should be blocking.

Whether we do display:revert or not cancel the animation is still under discussion, and it sounds like we are leaning towards not canceling the animation because it will be simpler to spec.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUc1erPCR1x9oncAGtMsKY_QkbifvhKAUDXDuE70D7WWw%40mail.gmail.com.

[Yoav Weiss]

Thanks!! Do I understand correctly, and we'd be able to adjust our implementation to whatever's decided, even after we ship? Or would that trigger breakage?

[Joey Arhar]

Yes I believe that we could change this behavioe after shipping.

I feel confident that we will get consensus before launching though.

[Yoav Weiss]

LGTM1

[Yoav Weiss]

Ahh, LGTM3.. :)