Authors: Florian Rivoal, Lea Verou
Contents
Animated images (as enabled by GIF, APNG, WebP) are in common use on the web, for a variety of reasons, such as:
- Purely decorative design elements
- States or transitions of UI elements highlighting various interactions
- Part of the content supplied by the author
- User-generated content
- (animated) image upload can be an explicit feature of the site (social media, image gallery, chat applications…)
- (animated) images may be included as a side effect of providing a rich text editor
- (animated) images may be received within rich text created in a different service (e.g. email)
By default, UAs autoplay these images, which can be jarring for users, especially in use cases where there are multiple images on a single page (e.g. image galleries) and violates WCAG, and currently, site authors have no control over this.
This leads to a user desire to control such animations. However, due to the diversity of usage, there is a wide range of use cases and desired UIs and user experiences, so making this an automatic or opt-in UA feature would not be sufficient.
To offer their users the best experience, websites need to control the playback experience, separately for each different uses of animated images. For example:
- Start paused and play on hover and focus
- Start paused with a play button and toggle between playing and paused states on click
- Autoplay unless
prefers-reduced-motionis on - Turn off autoplay for decorative images when
prefers-reduced-motionis on, while keeping animations on for those that are part of UI interactions
In some cases, this can already be done using alternatives to animated images, such as CSS animations, SVG, or `
A few examples amongst many of people asking for that type of functionality.
Numerous workarounds exist (further highlighting author/user demand), all with a variety of downsides. See the “Current Workarounds” section of the Images-in-video explainer for a brief discussion.
- Provide declarative syntax to enable/disable animation of images
- Handle images that are part of the content as well as decorative images
- Enable applying different settings to different images
- Enable simple user interactions (e.g. click to play)
- Work with existing markup and/or without
- Turning animated images into fully fledged video player. (This could be pursued separately, but is not the focus of this explainer.)
The proposed solution is a css property to control animation of images. At its most basic version, it would take the following form:
Name:
image-animationValue:normal|paused|running|controlledInitial:normalApplies to: see text Inherited: yes Computed Value: specified keyword
This property applies to:
- content images, which are part of the document, as defined by the host language.
In the case of HTML, this is the
<img>element (including its use inside the<picture>element). In the case of SVG, this is the<imgage>element. Images injected into the page though the CSScontentproperty on real (non-pseudo) elements are also considered content images. - decorative images: images injected into the page via CSS,
such as background images,
border images,
through the
contentproperty on pseudo elements, or any other reference to external images.
This property has no effect on other types of graphical content, such as <video> elements, or <canvas>.
Issue: what about <object>, <embed>, <svg>, or the <video> element's poster image?
When an element contains several decorative images (e.g. background images and border images), or if it contains both a content image and decorative images, the property affects them all. In the case of non-animated images, all values have the same effect (i.e. none).
- normal: The current behavior, as specified in HTML, with images auto-playing, in a loop, synchronized with other instances of the same image on the page
- paused: the image animation does not run.
- running: the image animation plays, without synchronization with any other instance of the same image on the page.
- controlled:
-
on decorative images: same as paused
-
on content images: initially, the image animation does not run and the first frame is displayed.
Additionally, if the underlying image actually is an animatable one, the user agent provides some UI to allow the user to play and pause the animation, and also makes the element focusable, so that the control may be interacted with. The specific control is UA defined, but must not change the dimensions of the image. Authors should not expect more capabilities from this control than the ability to play and pause the animation. If more is desired, consider using the
<video>element instead.
-
Turn off all image animations on the page:
:root { image-animation: paused; }Turn off autoplay on all images, showing UI controls for playback on animatable content images:
:root { image-animation: controlled; }Note that this can be applied just as easily by a site's author, a web extension, a user-stylesheet, without any modification to—or knowledge of—the site's markup patterns. Other uses could include a web-based email-client using this to keep animated images under control in HTML email.
Same as above, in response to a [user request for reduced motion](https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion): ```css @media (prefers-reduced-motion) { :root { image-animation: controlled; } } ```
Using some knowledge about how the site is structured, it is possible to fine tune the response to a preference for reduced motion, for instance suppressing non-essential decorative animations, keeping those that are informative components some UI element, and offering on-demand playback for relevant parts of the content.
@media (prefers-reduced-motion) {
:root { image-animation: paused; }
.loading-indicator { immage-animmation: normal; }
.funny-meme { image-animation: controlled; }
}The browser-provided controls are not the only way to start a paused image. Elaborate controls can obviously be build with custom markup and script, but simple cases can be done declaratively. For instance, you could start paused and play on hover and focus: ```css img { image-animation: paused; filter: grayscale(10%) contrast(50%) brightness(80%); } img:hover, img:focus { filter: none; image-animation: running; } ```
Interesting effects can easily be achieved in combination with other CSS: ```css .carousel { overflow: scroll; scroll-snap-type: both mandatory; } .carousel img { scroll-snap-align: center; image-animation: paused; } .carousel img:snapped { image-animation: play; } ```
The controlled value presented above is more complex than the rest,
so it is worth taking some time to explain
why it is a reasonable and important part of this proposal.
- Is it OK to have a CSS property affect UI?
- There is precedent for CSS properties affecting the presence of UI controls on elements: [`resise`](https://www.w3.org/TR/css-ui-3/#resize), [`overflow: scroll` or `overflow: auto `](https://www.w3.org/TR/css-overflow-3/#overflow-control).
- Do we need any such thing at all?
-
As discussed [in the example above](#ex-simple-controls),
a simple interaction model can be built without any additional markup nor JS;
and certainly arbitrary UI can be built if you allow for extra markup and JS.
However, in the general case, authors have no way of knowing which images are static and which are animatable. Without this knowledge, the choice is either to provide no controls at all, or controls even on static images that don't need it.
Enabling authors (and web-extension developers, and writers of user stylesheets) to disable by default unwanted animations, while keeping the ability to view them on demand, on existing content, is an important motivation for this feature. This is trivially achieved with this previously discussed rule, but out of reach otherwise:
@media (prefers-reduced-motion) { :root { image-animation: controlled; } }
- Couldn't we use pseudo-classes instead?
-
Something like an `:animatable` pseudo class would solve the above information problem,
and authors could build their UI from there.
But would it be better?
We should make easy things easy,
and provide a good user experience for users.
The example below shows what a typical browser-provided UI can be expected to look like,
and replicating that manually,
with good accessibility,
would not be easy.
- Shouldn't this be done in markup instead?
- Arguably that should be possible too. In [a different explainer](../images-in-video/README.md), we argue that the ability to use animated image formats in the `
Animated image formats such as GIF, WebP, or APNG include information about how many times the animation is supposed to run. This could be made into an overridable default, with alternate possibilities being specified in CSS.
normal | paused | [ [ running | controlled ] && [ once | loop ] ? ]
or more generally:
normal | paused | [ [ running | controlled ] && [ loop | <integer [1,∞]>] ? ]
This example shows how, when the user prefers reduced motion, memes in a image gallery could be paused by default, with a browser-provided play button, and run once only when activated, instead of their default state, which is to autoplay and (generally) to loop forever.
@media (prefers-reduced-motion) {
.funny-meme { image-animation: once controlled; }
}Here, in a hypothetical music playing application, artwork representing each album plays as a continuous animation when the element is focused or hovered.
.album-cover { image-animation: paused; }
@media not (prefers-reduced-motion) {
.album-cover:hover,
.album-cover:focus {
image-animation: running loop;
}
}The property above could be broken down into longhands
possibly similar to those of the animation-* family of properties
(image-animation-play-state, image-animation-iteration-count).
Depending on use cases,
additional properties inspired by animation-* properties could also be considered.
Note: if we want to go this way,
it might be better to rename some values discussed above;
names in this explainer were chosen to maximize self-explanatory power,
but if we want to be maximize similarity to the animation-* properties,
different names may be better.
For instance,
loop in animation-iteration-count is actually called infinite,
and once would be 1.
The paused value could be extended to give control over which frame of the image is displayed when it is stopped.
paused [ first | last | last-shown | <time> | <percent> | <number> ] ?
- Web pages can already contain animated images,
and appropriate
alttext is already expected to be provided. ”Cartoon coyote being squashed by a falling anvil“ or “cute dancing hamster” remains equally appropriate and evocative whether the animation is running or not. - Currently, screen readers typically do not chose to announce animated images differently from non-animated images, though they could if they wanted to. Similarly, it is not expected that they would announce paused or playing images any differently, though they could if they wanted to.
- Conversely, when the
controlledvalue is specified on an element containing an actually animated content image, the element does become focusable so that its controls can be operated, and screen readers should announce the element distinctly, similar to how they do for<video>elements. Note that there is precedent for changing the focusability of elements based on CSS: in addition to a few of properties which can suppress an elements focusability (e.g.display,visibility…),overflow: auto/scrollmakes elements focusable, only when there is something to scroll.
With regards to decorative images,
this property enables control over image animation cross origin,
without leaking any information about whether the image is actually animatable or not.
The computed value does not change based on this information.
The running value has effects that are visibly different on animatable vs non-animatable images,
but none of these differences are observable by the page itself.
With regards to of content images,
the controlled value causes the element to become focusable
so that the play/pause control can be keyboard-operated without needing to change the element's tab-index.
This effect is defined to only take effect if the image is actually animatable,
to avoid needlessly making elements focusable and showing disabled/unnecessary controls.
In the case of cross-origin images,
this change of focusability does enable the host page to know
whether the image is animatable or not,
which is otherwise not known from the <img> element.
We argue that this is an acceptable trade-off:
- There is not much to be gained from this information that isn't already known.
- Whether an image is present at the target URL at all can reveal important information about the user (e.g. whether they are logged in in a particular domain), but that is already knowable from image dimensions, and animatability does not add to this risk.
- It is in practice very unlikely that a site would be designed to serve both a static and an animated image from the same URL, choosing which to serve based on some user-dependent private information.
- Similar information is already being shared for videos:
the
<video>element exposes duration even for cross-origin videos. A static image is arguably a special case of an animated one with a duration of 0, so exposing that information is analogous. - There is a proposal to allow images in the
<video>element. If implemented, it means the situation would not just be analogous, but that whether an image is animatable would already be knowable cross-origin anyway.
See the explainer for “Images in <video>”.
Animated images are effectively videos without a sound track.
Allowing images in the <video> element would take advantage of the rich controls
and APIs afforded to HTMLMediaElement in general
and <video> in particular,
and is arguably plugging an obvious gap in the web platform.
These approaches are complimentary. While there is some overlap in terms of what they enable, they each cover use-cases that the other does not. Pursuing both would make sense.
…insert summary table showing overlap and differences…
…insert discussion of why that's not a full substitute, but of how both features can be made compatible with each other if that's desired…
Firefox's about:config has image.animation_mode,
which can turn off all image animations,
and Safari respects macOS's “auto-play animated images” setting (default on, can be turn off).
However, such settings are too blunt an instrument to handle all cases.
The browser doesn't know which images are decorative ones
whose animation can be suppressed outright when users want reduced motion,
and which are content,
which should remain viewable if desired
(but maybe upon clicking some play button or on hover).
As it is,
if the browser forcibly suppresses animation of images,
users will either no have means to individually turn them back on
(as is case for Safari and Firefox).
Alternatively, if they have some UI element for every paused image,
even the decorative ones with superfluous animations would get such a button,
and possibly worse if animated images are used as part of some UI component,
UI injected by indiscriminately by the browser might clash with the site's own UI.
Say, for example, that a flashy/tacky website has pulsating / sparkling images used as buttons.
It wouldn't be great if a GIF-stopping browser added play buttons onto that site's GIF-based buttons,
it's GIF-based checkboxes, etc.
But if it doesn't,
it also doesn't add them to animated images which are meaningful parts of the content,
since it doesn't reliably know which is which.
In a browser where image-animation is implemented,
this UI setting could continue to exist,
possibly implemented in different ways.
The most blunt way is to simply make all images non animated when the setting is on,
leaving the CSS property nothing to usefully take effect on.
More interestingly, the setting could be reinterpreted in terms of the CSS property,
@media (prefers-reduced-motion) {
*,
*::before,
*::after,
*::marker {
image-animation: controlled !important;
}
}Properties like animation-play-state: running | paused
or animation-iteration-count: infinite | <number [0,∞]>
have value space that are similar to what is proposed here.
We could consider treating animated images as CSS animations,
and making (all) existing animation properties apply to images with multiple frames,
and attempt to explain the fact that they are animated in terms of CSS properties,
gaining full control over them along the way.
However a “similar“ value space is not an identical value space:
- The some values of
image-animationare image specific and are missing fromanimation-play-state, and would not be generally applicable. animation-iteration-countlacks a value that can default to what the image specifies internally.- Various other
animation-*properties lack values that can express what images need. For instance, what aboutanimation-duration? - The initial values of the
animation-*properties are not appropriate for images.
Adding these missing values or smart intial / auto values is certainly possible,
but making the animation-* properties be capable of expressing normal image behavior would require significant extensions.
Even if that were done, unless an additional opt-in is added,
this is certain to cause web-compatibility problems,
as animation-* properties are widely used on all sorts of elements with decorative or content images,
and so far without any effect.
Turning it on would cause undesired effects in unsuspecting web-sites.
If the regular animation-* properties cannot be made to apply by default and would need significant retro-fitting anyway,
it makes little sense to try and shoehorn image animations into them,
even if there are similarities.
This section is a work in progress.
Here is a short list, to be expanded, of other things that were considered but did not seem like good solutions: