- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 23 Jul 2025 16:38:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[web-animations-2] Element.animate could allow keyframes to come from CSS declaration`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ydaniv: this was added a long time ago<br> <TabAtkins> ydaniv: 8 years ago<br> <TabAtkins> ydaniv: so this is a proposal to add a feature to Web Animations to allow animating now based on an array of JS objects, but rather using the name of a @keyframes rule that exists in the doc<br> <TabAtkins> ydaniv: there's an example in the first comment of the issue<br> <flackr> q+<br> <TabAtkins> ydaniv: I think this is super useful for using animation libraries, I'd use it immediately<br> <emilio> q+<br> <TabAtkins> ydaniv: so you can distribute CSS animations as a library, and apply them on demand in JS<br> <TabAtkins> ydaniv: should be straightforward<br> <romain> +1<br> <astearns> ack flackr<br> <TabAtkins> flackr: in the issue I saw there was a proposed alternative for a function to get the ekeyframes for a name<br> <TabAtkins> flackr: this seems more extensible, you can view or modify the objects<br> <TabAtkins> flackr: why are we going back to the string?<br> <ydaniv> q+<br> <TabAtkins> flackr: if the element isn't in the Dom we don't have a document to resolve the string against, etc. complicated<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: I just missed that part. I think the API sounds good<br> <TabAtkins> ydaniv: I just want it to be possible to declare your keyframes in CSS and use them. whether we use a string directly or fetch the keyframes by name and can then use them, either is fine by me<br> <astearns> ack emilio<br> <TabAtkins> flackr: in the limit i could see a way to load keyframes without even having to install them into the document, but that's a separate issue. this API design sets us up to make that possible, tho<br> <TabAtkins> emilio: two questions, one might be solved by the API just discussed<br> <TabAtkins> emilio: so one is what to do if the element is in a shadow Dom.<br> <TabAtkins> emilio: those names are generally scoped<br> <TabAtkins> emilio: if you do the obvious thing, so the name comes from the shadow the element is in, that makes global names not visible, probably not what you want<br> <TabAtkins> emilio: if we instead have a querying API that's probably not an issue<br> <ydaniv> q+<br> <TabAtkins> emilio: two, it feels a bit risky to put the burden of synchronizing stuff....<br> <TabAtkins> emilio: we have some issue with document.fonts, it depends on @font-face<br> <TabAtkins> emilio: somebody runs script, the stylesheet might or might not exist, might not have loaded yet<br> <TabAtkins> emilio: but that might be workable<br> <TabAtkins> emilio: I don't see an alternative to waiting for stylesheets, besides maybe just taking a @keyframes string that can be parsed directly by the JS api<br> <TabAtkins> TabAtkins: that's what flackr mentioned as a possibility, yeah<br> <TabAtkins> emilio: right, I think I like that a bit better, you don't need to evaluate MQs to resolve the name, etc<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: so regarding scope, I think we resolved that last TPAC, noam had an issue about @keyframes scoping<br> <TabAtkins> ydaniv: I think this is already resolved<br> <TabAtkins> emilio: it's well defined when the name is in a stylesheet, but do you want to resolve it like the style attribute? not sure that's quite what we want<br> <TabAtkins> q+<br> <TabAtkins> ydaniv: I think this is just like the style attr, yeah. if your element can see a keyframes name, you should be able to use it in Web anim<br> <TabAtkins> ydaniv: you're already able to use timelines for scroll animations without having to use scoping<br> <emilio> scribe+<br> <emilio> TabAtkins: didn't we moments before that we should indeed not do the string thing?<br> <emilio> ... to have a document api to parse or query a name at the document level<br> <flackr> +1 that's my preference<br> <emilio> ... then this is not an issue<br> <emilio> ydaniv: yeah, sure, sounds good<br> <emilio> emilio: yeah agreed<br> <TabAtkins> astearns: so let's take back to the issue and rejigger to use a keyframes object instead of a string<br> <TabAtkins> flackr: ideally have the proposed functions we want to add, yes<br> <TabAtkins> flackr: being able to parse keyframes would also be useful but dont' need it initially, yeah. just having an object repr for it would allow it in the future while unblocking us for now<br> <TabAtkins> emilio: my concern about it is you need to do sync work to resolve the name, it can depend on the MQ states...<br> <TabAtkins> emilio: or we could just resolve that we only resolve top-levle keyframes<br> <TabAtkins> I don't understand why the potential dependency on an MQ is a problem here...<br> <TabAtkins> astearns: let's take this back to the issue and talk about the issues there<br> <TabAtkins> ydaniv: sounds good<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2070#issuecomment-3109367051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 July 2025 16:38:47 UTC