- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 23:56:27 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images] Disabling image animation`, and agreed to the following:
* `RESOLVED: adopt image-animation feature as a new ED, will decide final spec location later`
<details><summary>The full IRC log of that discussion</summary>
<TabAtkins> florian: in Paris, Lea and I made a presentation of an explainer about the problem space of animated images, and the desire to something stop them<br>
<TabAtkins> florian: this seems to be more of a pile of overlapping sue-cases<br>
<TabAtkins> florian: some is best solved in HTML, some in css<br>
<TabAtkins> florian: won't redo the presentation, it's still online<br>
<TabAtkins> florian: but just for the CSS part, we agreed vaguely that we'd try to solve this osmehow<br>
<TabAtkins> florian: i've made a first draft spec starting from a scaled-back version of the explainer, removing more controversial bits<br>
<astearns> previous presentation: https://webplatform.design/talks/image-animation/<br>
<TabAtkins> florian: single property, three values. normal (do normal thing, sync them if multiple of the same image) | running (run, no need to sync) | paused<br>
<TabAtkins> florian: I haven't specced a requirement for the UA to provide this option<br>
<TabAtkins> florian: but do have a pseudo-class for whether the image is animated or not<br>
<TabAtkins> florian: so authors can provide stopping UI just on relevant images, not on a static jpeg<br>
<TabAtkins> florian: this is an early draft. seokho from igalia is working on it<br>
<TabAtkins> florian: still several questions, Chris asked one in the issues<br>
<TabAtkins> florian: i'm not looking to resolve on issues today, just introducing the draft.<br>
<TabAtkins> florian: seokho can show us how far along we are<br>
<TabAtkins> florian: but the general request is if we can work on this draft in the WG?<br>
<florian> https://webplatform.design/projects/image-animation/image-animation-property/spec/overview<br>
<TabAtkins> florian: ^^^ link to the draft spec<br>
<seokho> https://cloud.igalia.com/s/wtsTZnPximaNpGn<br>
<TabAtkins> seokho: the live demo isn't ready, but I recorded a video of the built version<br>
<TabAtkins> [chattering about the demo]<br>
<iank_> q+<br>
<smfr> q+<br>
<TabAtkins> florian: there's a q about how you restart when you go from paused to unsynced, or from synced to unsynced. do you start from where you are, or back from 0<br>
<lea> q+<br>
<TabAtkins> florian: not answered today, we'll look into it<br>
<TabAtkins> florian: on the left we have image running normally, on the middle it's paused.<br>
<TabAtkins> florian: on the right there's a minimal UI from the author letting you toggle the value<br>
<TabAtkins> florian: so can we import this draft, along with explainers?<br>
<dholbert> q+<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about pause vs static<br>
<seokho> The implementation / wpt FYI: https://chromium-review.googlesource.com/c/chromium/src/+/7525787<br>
<TabAtkins> fantasai: we use the term 'play' in the other APIs rather than 'running'<br>
<TabAtkins> lea: animation-play-state uses running|paused<br>
<TabAtkins> fantasai: great<br>
<TabAtkins> fantasai: if you pause, does it pause at that point it was at, or reset to 0?<br>
<TabAtkins> florian: I don't have a strong opinion on this. would like to get a sense from impls on whether there's a difficulty diff between the two<br>
<TabAtkins> florian: I suspect going back to frame 0 is okay. this isn't a movie<br>
<TabAtkins> (I have a use-case for *not* resetting it)<br>
<TabAtkins> florian: you aren't usually trying to seek either way<br>
<TabAtkins> florian: this could be extended with more variants<br>
<TabAtkins> fantasai: I think we just need two states, pause at 0, and pause where it currently is<br>
<astearns> ack iank_<br>
<fantasai> image-animation: normal | static | paused | running<br>
<TabAtkins> fantasai: not at 0, at the "static" version. depending on image format might be 0 or something different<br>
<TabAtkins> iank_: is this all images on the element, or a specific image?<br>
<TabAtkins> florian: all of the images on that element<br>
<fantasai> where running continues from wherever it is (with static treated as the start for this purpose)<br>
<TabAtkins> iank_: is that desirable?<br>
<TabAtkins> florian: it's simpler. unsure about use-cases for more<br>
<TabAtkins> iank_: I just think we could possibly do this only for content images<br>
<TabAtkins> smfr: dynamic-range applies to all images on the element<br>
<TabAtkins> TabAtkins: but image-rendering is only the content image, so precedent both ways<br>
<TabAtkins> iank_: where is the state stored for what state you're paused on?<br>
<TabAtkins> florian: what do you mean?<br>
<TabAtkins> iank_: browser engines deconstruct box tree for a number of reasons. so you can't store the "current frame" state there.<br>
<TabAtkins> iank_: in-flow to out-of-flow, some engines fully tear down the tree and rebuild<br>
<TabAtkins> iank_: good reasons for the disparity between engines<br>
<TabAtkins> iank_: so we'll need to agree on where the state lives, on something in the DOM tree most likely, since we agree on that lifecycle<br>
<emilio> q+<br>
<TabAtkins> TabAtkins: "last remembered size" is stored on the element, for example, for this reason<br>
<TabAtkins> TabAtkins: you can crib some wording from content-visibility<br>
<astearns> ack smfr<br>
<ChrisL> q?<br>
<TabAtkins> smfr: the simplest version of this feature is just auto|paused, right?<br>
<TabAtkins> smfr: sometimes if you have a bunch of frames you have to go back and decode things...<br>
<TabAtkins> smfr: so not having running would be simpler<br>
<TabAtkins> smfr: but would it be okay to just have those two values?<br>
<TabAtkins> fantasai: what's diff between normal and running?<br>
<TabAtkins> florian: [explains]<br>
<fantasai> s/running/auto/<br>
<TabAtkins> smfr: i'm actually arguing for an "auto", so the UA can decide how to restore the image<br>
<TabAtkins> TabAtkins: florian was just arguing for "normal" being to put the image on the timeline that HTML already requires "same images" to work on<br>
<TabAtkins> TabAtkins: UAs can still pause that timeline if the images are off screen, etc<br>
<ChrisL> q+<br>
<astearns> ack lea<br>
<TabAtkins> florian: but if trimming "running" is necessary for v1, that's acceptable. igalia is already doing it so it's not too hard<br>
<kizu> q+<br>
<TabAtkins> lea: is the main use-case just user-generated content, so <img> content?<br>
<TabAtkins> florian: probably true, but people do use images in lots of ways, so higher applicability could capture more of these<br>
<TabAtkins> florian: I think one possibility is a MQ (prefers-reduced-motion, for example) they pause *all* images, CSS and content, and then inject controls for content images to let them selectively start<br>
<TabAtkins> lea: for sync vs unsync, I have some thoughts<br>
<TabAtkins> lea: two big use-cases, user action that unpauses, or big MQ or something<br>
<TabAtkins> lea: if aggregate, showing poster while paused is better. if user-initiated, jarring to have it jump to another frame<br>
<TabAtkins> lea: similarly, if user-initiated, jarring to have to start playing and jump back onto a timeline that's progressed, but if it's aggregate, fine to<br>
<TabAtkins> lea: also, with multiple images, until you pause at least once, normal|running are the same<br>
<TabAtkins> florian: if all images were added simultaneously, running|normal are the same. but if they're added dprogressively, that could be different<br>
<TabAtkins> florian: you add an image, then a second later add a second instance, does it start aligned or not? current HTML spec requires that they sync<br>
<TabAtkins> emilio: if you switch two images to running at the same time. are you guaranteed that they're on the same timeline?<br>
<TabAtkins> florian: no, they're living their own lives now<br>
<TabAtkins> emilio: so the UA could pause one if they're out of view<br>
<TabAtkins> florian: yes<br>
<astearns> ack dholbert<br>
<TabAtkins> dholbert: similar to smfr, I'd go for a 2-value first, where paused means the first frame if we could<br>
<TabAtkins> dholbert: simpler for our internal image APIs<br>
<TabAtkins> dholbert: sounds like that would match many of th euse-case you're describing, setting all images to paused by an MQ<br>
<TabAtkins> dholbert: just a little awkward if the user pauses a single running image, it can jump<br>
<florian> q?<br>
<florian> q+<br>
<emilio> ack emilio<br>
<TabAtkins> dholbert: we should consider animated SVG as part of this<br>
<TabAtkins> florian: yeah I want to ask that question too<br>
<astearns> ack ChrisL<br>
<lea> +1 ChrisL<br>
<TabAtkins> ChrisL: make things as simple as possible but no simpler<br>
<TabAtkins> ChrisL: the 2 values are simple, but are they too simple?<br>
<lea> q+<br>
<TabAtkins> ChrisL: the horse zoetrope animation, very useful to pause at a specific frame.<br>
<TabAtkins> ChrisL: worried if we over-simplify then people will still just turn to script<br>
<astearns> ack kizu<br>
<TabAtkins> q+<br>
<TabAtkins> kizu: big +1 to the feature<br>
<TabAtkins> kizu: I think it's important to pause all images, not just content images<br>
<TabAtkins> kizu: it is not only an author tool when you can apply as MQ, it's an a11y tool where users can disable animations on their own<br>
<TabAtkins> @document URL(hamster dance.com) { * { image-animation: paused; }}<br>
<TabAtkins> kizu: also, authors don't always use content images, they use background images many times, sometimes even in conjunction with a content image<br>
<TabAtkins> kizu: with an animation you'd want to stop both of them<br>
<astearns> ack florian<br>
<TabAtkins> kizu: also, visual integration testing, would like to pause all animations and image would be very useful to ensure a stable sdcreenshot<br>
<TabAtkins> florian: I have a lot of things to talk about but unsure how deep I want to go today<br>
<TabAtkins> florian: briefly, does this apply to SVG as image? I think yes. when embedded in HTML? I think no.<br>
<TabAtkins> florian: this doesn't apply to video. but what if an animated poster image?<br>
<TabAtkins> florian: is this a video state and it doesn't apply? or is it an image and it does? various things to explore.<br>
<TabAtkins> florian: mostly I just want to see if we can adopt this and continue the discussions<br>
<schenney> q+<br>
<TabAtkins> florian: I propose we adopt the draft as is, with two more issues<br>
<TabAtkins> florian: 1) do we really need all three values or can we do just 2, and 2) do we need variations for paused/running that "reset" vs continue from current?<br>
<TabAtkins> florian: if we adopt, would like to start talking to horizontal groups and TAG, that's easier with a FPWD rather than an ED<br>
<TabAtkins> florian: so are we willing to take it on, and ED or FPWD<br>
<TabAtkins> ChrisL: difference is FPWD triggers an exclusion opportunity, so you want to decide when to do it.<br>
<TabAtkins> ChrisL: suspect you want to make sure you're ready before triggering it. don't want to publish FPWD with 2 values, later add 3 and realize someone's got a patent on that<br>
<astearns> ack fantasai<br>
<TabAtkins> ChrisL: not blocking progress, just suggesting strategy<br>
<TabAtkins> fantasai: we could do a separate property for decorative images. but roman's argument for a single property seems good, so go with one until we have a good argument otherwise<br>
<TabAtkins> fantasai: for first vs static frame, don't think we should have that choice, should always be static<br>
<TabAtkins> florian: ah wasn't talking about that, meant static vs current frame<br>
<astearns> ack lea<br>
<TabAtkins> lea: generally +1 to adopting in some form<br>
<TabAtkins> lea: unsure where it would go<br>
<TabAtkins> fantasai: images?<br>
<TabAtkins> florian: was thinking of new things, but okay with Images<br>
<schenney> +1 images<br>
<TabAtkins> lea: for use-cases for going to the beginning, unsure you ever *want* it to. just cases where it's not very jarring to happen<br>
<TabAtkins> lea: so I think from user-facing pov you only really want paused|running<br>
<TabAtkins> lea: maybe we just have auto|paused, and auto can sync when it's reasonable<br>
<TabAtkins> lea: I wonder if impl-wise it's reasonable to capture a freeze frame... authors today capture into canvas and replace the source<br>
<TabAtkins> lea: maybe UAs can do that internally<br>
<TabAtkins> lea: that solves SVGs too<br>
<TabAtkins> lea: for videos, should apply when in an <img><br>
<TabAtkins> (we can't do that yet, it's still under discussion after years)<br>
<TabAtkins> lea: WebKit supports that<br>
<TabAtkins> lea: same with poster image on <video>, it's an image at that point<br>
<astearns> ack TabAtkins<br>
<astearns> ack schenney<br>
<emilio> TabAtkins: my use case for pausing on current frame is the popularity of animated images that roll and pause on a frame on click<br>
<emilio> ... everybody loves that shit<br>
<TabAtkins> schenney: I agree on pausing and restarting from there is compelling to users.<br>
<TabAtkins> schenney: may be hard to impl particularly for long-running animated images<br>
<TabAtkins> schenney: we'd have to look into it<br>
<TabAtkins> schenney: for others... i'm not sure we'd animate a gif as a <video poster>, would have to check anyway<br>
<lea> q+<br>
<florian> q?<br>
<astearns> ack lea<br>
<TabAtkins> lea: if the video poster isn't currently animated, could explain that as a UA stylesheet rule `video { image-animation: paused; }`<br>
<ChrisL> q+ to mention PNG static image options<br>
<TabAtkins> lea: for paused/sync, for decorative images it's okay to go from sync to stopped, don't really care where it even happens. mostly content images you'd want that control<br>
<dholbert> video poster with animated-gif *does* seem to currently be animated. Testcase: data:text/html,<video poster="https://gifcities.org/static/gifsearch/search.gif"><br>
<TabAtkins> florian: in terms of use-case I think I agree, in terms of existing usage I dunno<br>
<astearns> ack ChrisL<br>
<Zakim> ChrisL, you wanted to mention PNG static image options<br>
<TabAtkins> florian: people use content images for decorative all the time, and CSS backgrounds as content images all the time<br>
<TabAtkins> ChrisL: poster attr was mentioned<br>
<TabAtkins> ChrisL: png also always has a static image.<br>
<TabAtkins> ChrisL: when you make it apng, you have a choice; static image is the first frame, or as soon as you play it replaces the static image<br>
<TabAtkins> ChrisL: so just clarifying that we do mean the static image, not the first frame<br>
<TabAtkins> astearns: sounds like we have a lot of issues, but general agreement with the problem.<br>
<TabAtkins> astearns: suggest we adopt an ED, and decide when it's FPWD time on whether it's a new draft or part of Images<br>
<ChrisL> +1<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: adopt image-animation feature as a new ED, will decide final spec location later<br>
<smfr> animated images play in <video poster=> in webkit<br>
<seokho> Maybe for more issues:<br>
<seokho> https://github.com/webplatformco/project-image-animation/issues<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1615#issuecomment-3821018168 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 23:56:28 UTC