- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 11:41:05 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images] Disabling image animation`, and agreed to the following: * `RESOLVED: Try to solve this problem` <details><summary>The full IRC log of that discussion</summary> <florian> https://webplatform.design/talks/image-animation<br> <fantasai> florian: Image animation on the web needs some control<br> <fantasai> florian: Animated images, there are GIFs, APNG, WebP, etc. Not specific to a format.<br> <fantasai> florian: These are everywhere and here to stay<br> <fantasai> florian: Not just Geocities, but people love animated memes<br> <fantasai> s/memes/memes and emojis/<br> <fantasai> florian: OSmetimes used for animated icons<br> <fantasai> florian: Diagrams can be animated, or maybe you have animated backgrounds<br> <fantasai> florian: In many cases even user-generated content<br> <fantasai> florian: Typically embedded with <IMG><br> <fantasai> florian: However, uncontrollable animations are a WCAG violation<br> <fantasai> florian: can trigger motion sensitivities, cause attention problems, or generally be annoying<br> <fantasai> florian: UAs have a pref to turn all animations off, unconditionally, everywhere -- but sometimes you want them<br> <fantasai> florian: Authors need to accommodate for user needs/preference, but doing that depends on the use of the animation<br> <fantasai> florian: Disabling animated background vs animated meme vs contentful image, differs<br> <fantasai> florian: Then there's question of is it new content, old content, user-generated content, etc.<br> <fantasai> florian: Authors do care: see stack overflow, reddit, polls by Lea, etc.<br> <fantasai> florian: There are some workarounds, but not perfect<br> <fantasai> florian: Can do server-side to create set of frames and convert to mp4, but this is expensive<br> <fantasai> florian: clients side, but then only possible same-origin<br> <fantasai> s/clients side/client side extraction into <canvas>/<br> <fantasai> florian: in any case, these are complicated options<br> <fantasai> florian: Very simple solution would be 'image-animation: normal | pased | running'<br> <fantasai> florian: Put it on the root depending on prefers-reduced-motion, and let it inherit<br> <fantasai> florian: then select the ones you want to enable and flip it to 'running'<br> <fantasai> florian: "prefers-reduced-motion" isn't "never-animate"<br> <fantasai> florian: so, e.g. could be running on focus or hover<br> <fantasai> florian: (but then focusability of images is an issue)<br> <fantasai> florian: But for images with meaningful content, authors likely want to provie play/pause controls<br> <fantasai> lea: One idea is to allow images in <video>. This doesn't require any new API surface. Just a video with no audio track.<br> <fantasai> lea: Allowing images in <video> give syou full playback control, have a JS API to control, can enable looping, disable autoplay, even adjust speed<br> <fantasai> lea: Designed to be extensible, so will benefit from future extensions<br> <fantasai> lea: Proposed to WHATWG, initial reactions are promising<br> <fantasai> lea: But doesn't solve everything because a lot of existing content and infrastructure that uses <IMG><br> <fantasai> lea: and also controlling via selectors is not possible<br> <fantasai> lea: So another idea is what if adding control attributes to <img><br> <fantasai> lea: Can have same element as before (<img>), and tailor the UI to images rather than video<br> <fantasai> lea: But then we have to introduce new API surface, and awkward interface for boolean attributes that is opposite default of <video><br> <fantasai> lea: Also can't respond to media queries<br> <fantasai> lea: or use selectors to control<br> <fantasai> lea: One idea is very high-level solution, to add a 'controlled' value to image-animation<br> <fantasai> florian: If we have the CSS property we discussed earlier, and we have images in <video>, and we have <img> + CAS, we are solved<br> <fantasai> florian: but CAS is specifiction right now<br> <fantasai> florian: Setting up <img> for controls is also not easy<br> <fantasai> florian: May or may not fly, so what else?<br> <fantasai> florian: So 'controlled' is a solution<br> <fantasai> florian: For background images etc. no effect, but for content <img>, would provide a play/pause controls *if* it's an animatable image<br> <fantasai> florian: responds to selectors, media queries, can work on older sites and user-generated content<br> <fantasai> florian: But if down the line we have images with controls, interactions between the two might be odd, and weird layering of things<br> <fantasai> lea: Another option is to expose lowlevel primitives, so authors can do it<br> <fantasai> lea: If you want control over playback, use a video<br> <fantasai> lea: but could also expose low-level primitives like an image::overlay pseudo-element to paint stuff over the image<br> <fantasai> lea: or img:static to target non-animated images from animated ones<br> <fantasai> lea: or connect into CSS Animations machinery, e.g. animation triggers<br> <fantasai> lea: These would be more useful more broadly<br> <fantasai> lea: We do have general tendency of generalizing, e.g. can play audio in <video><br> <fantasai> lea: so unifying image is along these lines<br> <fantasai> lea: But simple things would not be easy with primitives<br> <fantasai> lea: and you can mess up author interactions, e.g. forget to put tabindex to make it focusable<br> <fantasai> lea: would be handled automatically if we had a controls attributes<br> <fantasai> lea: For CSS images, could have image-frame() to extract frames. But ocntrol over playback is tricky<br> <fantasai> lea: and e.g. pausing all images, you would need ability to style them all, which is not so simple for e.g. background imgaes<br> <fantasai> lea: Suppose if we went down the @image path for determining image tweaks, calling it with image(src options-name).<br> <fantasai> lea: Then you could attach animation controls.<br> <fantasai> lea: Or maybe we could hook up image animations to animation properties by using an image-animation() function to "name" the animation in animation-name and control it with animation-play-state<br> <fantasai> lea: But then everything becomes a list, it's maybe a bit awkward.<br> <fantasai> lea: Anyway, these are the thoughts.<br> <fantasai> florian: What we are most likely to pursue is what everyone else is interested in<br> <fantasai> florian: But images in video definitely given response in WHATWG<br> <fantasai> florian: But we are also considering proposing image-animation property for CSS<br> <fantasai> florian: Independently of that, whether Cascading Attribute Sheets becomes a thing, might determine the next steps<br> <fantasai> florian: But anyway, let us know which ideas you're interested in<br> <fantasai> lea: wrt resolutions, maybe just "we want to solve the problem"...<br> <SebastianZ> q+<br> <ydaniv> q+<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <fantasai> ydaniv: All of this is awesome. Lots of good ideas.<br> <fantasai> ydaniv: Currently animated images is a child that nobody wants, because it hurts performance so much<br> <lea> qq+ to reply to ydaniv<br> <fantasai> ydaniv: Animated images are very eager. Can cause everything on the page to freeze.<br> <astearns> q+ SebastianZ<br> <fantasai> ydaniv: That's one of the biggest issues, so maybe going through the medium direction and somehow make them streamable...<br> <fantasai> florian: Is the heaviness due to inefficiency of image format and it overhwelms the page or ....?<br> <fantasai> ydaniv: sometimes ppl make an animated sequence from a video, and then put it into ??<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to bramus to reply to ydaniv<br> <fantasai> lea: A lot of animated images are inserted by users *because* they're animated<br> <fantasai> lea: Unsure if webP is as inefficient as e.g. GIF<br> <astearns> ack SebastianZ<br> <lea> s/*because* they're animated/*because* they loop and autoplay. Once websites have control over this, it could remove one of the motivations for using gifs/<br> <fantasai> ydaniv: Issue about hooking video playback to animations, so allowing for animated images, people would be very happy<br> <fantasai> SebastianZ: Reporter of the issue related to this is one of the Firebug contributors<br> <fantasai> SebastianZ: Wrt animations, good idea to allow users to get some control over the animations<br> <fantasai> SebastianZ: Presented solutions are not necessarily exclusive<br> <lea> q+<br> <fantasai> SebastianZ: One thing I was missing in the presentation was the idea of having a param for the url() functions to control it<br> <emilio> q+<br> <fantasai> SebastianZ: e.g. to extract one frame from the image<br> <fantasai> lea: Mdia fragments are about getting a subresource<br> <astearns> ack lea<br> <fantasai> lea: extracting one frame might be seen as that, but playback control isn't<br> <fantasai> lea: Also, media frags isn't under charter atm...<br> <astearns> ack emilio<br> <fantasai> emilio: I see a lot less problems with the video approach<br> <fantasai> emilio: Making that apply to the CSS images is a bit more complicated<br> <fantasai> emilio: wrt pseudos, e.g. adding ::overlay would be OK if you only do for HTML images, not CSS images<br> <fantasai> emilio: ...<br> <fantasai> florian: In theory youc could have longhands for image-animation, but I think it woudl be rare to want to animate e.g. border but not background<br> <fantasai> emilio: Some precedent for having a property affect both content and style images<br> <fantasai> emilio: pseudo-element stuffs eems too limited to me<br> <fantasai> emilio: Controlling email animations would be helpful maybe<br> <fantasai> florian: the parts we're reasonably confident about are image-animation and <vedo><br> <fantasai> florian: everything else, all of them can sort-of solve it, but different tradeoffs<br> <fantasai> florian: I like tihs one is the easiest<br> <fantasai> florian: but from layering, maybe it's the worst and other thing is better -- but then not responding ot MQ<br> <fantasai> florian: full of tradeoffs for the rest, unsure<br> <SebastianZ> q+<br> <fantasai> [missed]<br> <fantasai> lea: we have tools for timeline controls<br> <fantasai> emilio: track of time that's not continueous... feels more exploratory<br> <astearns> ack SebastianZ<br> <fantasai> SebastianZ: Not totally convinced imgae-animation is right, because it's affects all CSS images<br> <fantasai> florian: Only a problem if you have multiple animations you want to control independently<br> <fantasai> florian: I'm not convinced, seems theoretical<br> <lea> s/lea: we have tools for timeline controls/lea: one question is do we design this very simple image-animation property, or do we find some way to hook into CSS animations and make use of all the elaborate playback controls we have for them?/<br> <ydaniv> q?<br> <ydaniv> q+<br> <fantasai> florian: We could expand into longhands if becomes necessary<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> florian: if you have multiple images you want to control independently...<br> <fantasai> emilio: Never got this issue with image-orientation<br> <fantasai> ydaniv: wrt loading, if we put this in CSS it doesn't affect loading of the images<br> <fantasai> ydaniv: would be nice to say "load this images, but only load the first frame"<br> <fantasai> florian: I think this would be possible if you go through the the HTML route<br> <astearns> fantasai: agree with florian you’re unlikely to want to independently control …<br> <fantasai> fantasai: if we really need to do that, put parameters into image()<br> <fantasai> fantasai: HTML only every produces one image per element<br> <fantasai> astearns: roposed to resolve ot solve this problem<br> <fantasai> RESOLVED: Try to solve this problem<br> <fantasai> astearns: Where should people contribute into?<br> <fantasai> florian: This is an old issue that discusses the issue, and proposal being discussed is similar to this idea<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-3210179592 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 11:41:06 UTC