[Feature policy: animations] Description of animations needs review

[birtles]

The feature policy description appears to have a lot of inaccuracies. e.g.

In order to produce animations on the web, developers declare transitions inside of CSS.

Or CSS animations, or Web Animations, or SVG SMIL, or JavaScript.

One way to avoid this scenario is to move the animations off of the CPU entirely. Modern desktop computers and mobile devices have powerful GPUs that can perform certain kinds of animations much more efficiently, and can leave the CPU free to handle other things, like responding to user input.

The animations still run on the CPU. The GPU is just used for much of the heavy-lifting of producing each animation frame.

Many (most?) CSS properties are interpolable

Most CSS properties are not "interpolable". See how many properties have a 'discrete' animation type in property-list.js.

Furthermore, "interpolable" is not dependent just on the property, but on the specific values being used (e.g. auto cannot currently be smoothly interpolated with 100px).

Other properties are not interpolable -- there is no such thing as an intermediate state -- font-face, for instance, or background-image

background-image can be interpolated in Webkit-based engines (including Blink) using cross-fade().

[ehsan-karamad]

Thanks for filing these. I will get back to this thread and fix the explainer after concluding the main promise of the feature mostly discussed in issues #10 and w3c/webappsec-permissions-policy#204.

[ehsan-karamad]

Reviving this thread as the animation policy has been reworked. It no longer deals with composited animations and is now about disabling certain layout animations instead. Please, take another look.

[birtles]

Thanks for addressing my comments. I'm afraid the are still a few inaccuracies (e.g. there's no size property in CSS, a number of transition events are omitted, etc.). Also the part about blocking animations should be rephrased in terms of discrete animation.

More importantly, however, I still don't think we'd be interested in implementing this--the animations() feature in particular seems to encourage coding to the performance characteristics of a particular version of a particular user agent on particular hardware. layout-animations too brings some similar concerns (since some UAs can sometimes animate position properties without re-running layout if the elements are absolutely positioned).

[ehsan-karamad]

(apologies for the delayed response)
Thanks for the comment's and corrections. I created the pull request w3c/webappsec-permissions-policy#239 to address the mentioned issues.

AFAIK on Chrome the aforementioned animations do not always lead to re-running layout; the policy is based on assuming the worst, i.e., if the animation can in general cause layout changes then it will be disabled. Understandably this would block certain animations which would not have caused re-layout; however the policy is meant to be a promise on decreasing the number of layout runs on a page and ideally lead to more responsive pages.