[css-images] Disabling image animation

[simonlindholm]

It would be nice to have a CSS property for disabling image animation. Use cases include:

• thumbnails
• Twitter-like "only animate images in focus"
• not wanting to animate user-uploaded content
• user stylesheets/extensions

I'm imagining something like image-animation: auto | none, where none would disable image animation on elements and background-images.

Semantics are slightly subtle to define, because HTML defines image animations as keyed by URL, instead of per element. I can think of two options:

• Paused images show the first frame (like how canvas's drawImage behaves)
• Images that are ever shown as paused are animated individually

where the second seems tricker to implement (e.g., might include cloning SVG documents?) but also more useful than the first.

[Crissov]

Perhaps add once or <integer> for repetitions; maybe <time> as well. Some users might want to force continuous loops even if the animation resource specifies a limited number of iterations, so loop or continuous makes sense as well.

Some animation formats distinguish a still poster frame from the first frame. You would probably have to specify which would be used when.

[simonlindholm]

Perhaps add once or <integer> for repetitions; maybe <time> as well. Some users might want to force continuous loops even if the animation resource specifies a limited number of iterations, so loop or continuous makes sense as well.

Yep, that definitely fits. The use-cases for it seem weaker, though, and with that level of control you might want a <video> element anyway, so probably worth punting on for a first iteration at least.

Some animation formats distinguish a still poster frame from the first frame. You would probably have to specify which would be used when.

Do you know which ones? (I imagine the answer would be the same as for canvas's drawImage, whatever that does.)

[Crissov]

APNG, for instance, can include PNG’s standard IDAT chunk data as the first frame or treat it as a fallback still image.

[DanHarkless]

Simon, thank you very much for opening this issue. I think it's much more than a "nice to have", though. The Web Content Accessibility Guidelines require that users be given the ability to pause, stop, or hide any animation that starts automatically and lasts more than 5 seconds (e.g. looping animated GIFs and PNGs). This is as it should be, since, for example, users with hypervigilance (little to no ability to employ selective attention) are unable to "just ignore" or "tune out" distracting extraneous animations in the field of view.

Firefox (and previously Netscape), for example, originally had the ability to stop animated images by pressing the Stop button or hitting the Esc key. Then this ability was eliminated as a side effect of fixing an XMLHttpRequest bug, and now browser add-ons must be installed in order to restore it. Unfortunately these add-ons utilize browser hooks that will no longer be available when Firefox support for add-ons other than WebExtensions is eliminated in November 2017.

Currently, WebExtensions and user stylesheet overrides have no ability to stop image animations, so it seems that a new CSS property is required to allow browsers like Firefox to meet this aspect of the W3C accessibility guidelines (and thus handle the myriad of sites whose webmasters do not implement the WCAGs).

[tabatkins]

Firefox (or any browser) doesn't need a CSS property in order to control GIF/APNG playback. The current play position isn't even exposed to the web, except indirectly via what frames would get painted to a canvas at a given point in time. It's perfectly acceptable for a browser to give this sort of control natively, either thru a user setting or thru direct manipulation (stop/start gifs on click automatically).

The only reason to add a CSS property is if we think that page authors need this control, and such control is common enough that things like <gif-player> aren't sufficient.

[ssokolow]

The only reason to add a CSS property is if we think that page authors need this control, and such control is common enough that things like aren't sufficient.

Correct me if I'm wrong, but doesn't the same-origin poiicy render <gif-player> inapplicable for disabling animation on externally-hosted images from domains that don't set an appropriate CORS policy?

Also, the argument for using components like <gif-player> gives me serious concerns for user uploads, since it would basically require replacing every <img> tag with custom in-JavaScript infrastructure to retrieve the image, identify whether it's in a format the browser's native support might animate, and then feed it to a JavaScript-based AniGIF/APNG/etc. renderer if necessary.

Not only does that seem far too convoluted for something which is effectively a "troll security" measure to protect against users trying to disrupt other users' browsing experience (much like how one should use CSS to prevent user-submitted long strings of characters from causing changes to the layout beyond the scope of their post), it also seems like a potential performance issue and a decision which would disincentivize doing the right thing.

(And it would also be a solution ill-suited to "simple, static, meant-for-reading" pages (forums, wikis, etc.) where every other bit of mitigation for user-submitted content shenanigans (CSS, <bdi>, etc.) can be implemented readily without resorting to client-side JavaScript.)

In that latter case, it encourages people like me to take the risk of feeding all user-provided image content through server-side reprocessing to strip extra frames. (At the risk of exposing a vulnerability in the underlying image library which might be leveraged into an exploit across all browsers which visit the site.)

[tabatkins]

Not only does that seem far too convoluted for something which is effectively a "troll security" measure to protect against users trying to disrupt other users' browsing experience

This suggests that you think site authors are going to be the ones using this property. I don't see why they would, tho. Gifs are generally just fine to upload alongside any other images.

The need to stop/start a gif is either a per-user thing which should apply to all sites (and thus should be a browser setting), or should just generally be a functionality applied to all gifs for all users. I'm not seeing the use-case for an individual site author to need to turn on this functionality.

[ssokolow]

This suggests that you think site authors are going to be the ones using this property. I don't see why they would, tho. Gifs are generally just fine to upload alongside any other images.

Because I'm both someone with hypervigilance issues and a designer/developer with a strong desire to control when and where animated elements are allowed within the sites I produce. (If a muted <video> wouldn't be allowed, then I probably won't allow an animated <img> either.)

Hence my comment about using image-processing libraries server-side. (To limit the risk, I've taken to using a simple a pre-check stage which detects APNG and animated GIFs using only very limited, defensively-coded inspection routines before I feed only the animated stuff to the full parser.)

On my hobby sites, a lack of this has actually been one of the factors delaying a move away from full pre-moderation to a more wiki-like experience.

[AmeliaBR]

This functionality seems to me as a natural extension of the Media Fragments URI spec, assuming browsers ever get on board with fully implementing that spec. Then you could use something like:

<img src="user-upload.svg#play-state=paused"/>

background-image: icon.gif#t=2s&play-state=paused;

Using a URI hash to set the pause might help avoid the issue with HTML expecting all images with the same URL to animate in sync.

The downside, of course, is that you'd need to modify every URL, and therefore use JS to re-enable animations on content images.

Of course, it would also very much like a user-controlled browser feature to disable auto-playing GIFs, etc. But I do see a benefit to a website designer in being able to use these image formats but also being able to start and stop them.

[MarjaE2]

I don't know much about programming, but I get nasty migraines and other symptoms from flashing, zooming, and some other animation. Some people get seizures. So it can be important for users to be able to disable animation [including transform and transition and so on], easily, and before we get hit by the animation.

[SebastianZ]

I get nasty migraines and other symptoms from flashing, zooming, and some other animation. Some people get seizures. So it can be important for users to be able to disable animation [including transform and transition and so on], easily, and before we get hit by the animation.

That's a very good point. I would say, this is something the user should be in control of, not the website author. I.e. disabling all animations should rather be an option in the user agent than a CSS feature.

Simon's use case is to allow to disable only image animations, and that selectively per image.

Sebastian

[ssokolow]

I think it makes more sense for it to be a matter of precedence. The user can overrule the website and the website can overrule the resource.

(ie. I can disable all animation on a site, but even if I don't, the website should have the ability to disable animation on external or user-uploaded resources without having to incorporate potentially insecure libraries for reading and writing the formats in question in order to strip extra frames as is currently necessary.)

[Malvoz]

Personally I don't know if this is needed, but to add a use-case, see @media (prefers-reduced-motion).

[tabatkins]

At that level, it's something the UA should be applying, not something the page author is in charge of. That MQ is for alerting the author about things like animations and such, which are in their control and can't be automatically suppressed (since styling sometimes depends on them; just ignoring the animation can leave the element in an unusable default state).

[easrng]

I'd love this, I maintain a PWA social media client that interfaces with multiple different servers, and not all of them offer static versions of images. Right now if I wanted to ensure all images are static I would need to render every image to a canvas before inserting it into the DOM, which is cumbersome and also breaks progressive image decoding.

[Seirdy]

This could also be an HTML attribute, as only showing the first (or nth?) frame of a slideshow could be a content decision rather than a presentation one. Just as HTML attributes can determine when to load an image (loading) or whether to display one (hidden), they should be able to determine whether to load the rest of an animation's frames.