- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 11 Mar 2026 16:37:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Allow animations on ::first-letter and ::first-line similar to ::marker`, and agreed to the following: * `RESOLVED: animations and transitions work on all tree-abiding` * `RESOLVED: On non-tree-abiding, animations work, and transitions are intentionally optional right now.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> astearns: looks like convo says "yeah let's do it"<br> <emilio> q+<br> <TabAtkins> dbaron: i'm not sure how much the specs for ::first-letter/line and impls match right now, and before we add animations we should make sure they agree<br> <emilio> +1<br> <TabAtkins> dbaron: for things like what inheritance and fictional tag sequence is<br> <TabAtkins> dbaron: the other thing I'm unsure about is whether it's asking only about CSS animations, or about animations and transitions<br> <TabAtkins> dbaron: when people talk about animations they sometimes mean T&A, and I think transitions is scarier if we don't have that interop<br> <astearns> ack emilio<br> <TabAtkins> (agree, animations seems pretty clear in its behavior, it's just setting values. reacting to values in transitions is trickier)<br> <TabAtkins> emilio: agreed<br> <TabAtkins> emilio: intention seems to be the computed values apply to the root of the first-letter style "box", and whatever comes out of inheritance from that just "happens"<br> <TabAtkins> emilio: given the state of interop for these pseudos, i'm not a fan of piling more stuff into it before solving those issues<br> <TabAtkins> astearns: and while I summarized the convo as 'let's do it', I was reading Rob's comment wrong. he was saying "there's no reason not to, except it would be hard"<br> <astearns> ack fantasai<br> <TabAtkins> flackr: right, I was saying it' is unlikely we could implement soon because eit would be complicated<br> <TabAtkins> fantasai: I feel like theoretically there's no strong reason to not do it, but if it's difficult to impl it's not a high prio<br> <TabAtkins> fantasai: it sounds like the issue is non-tree-abiding pseudos<br> <TabAtkins> fantasai: and for tree-abiding it's fine?<br> <TabAtkins> flackr: right<br> <TabAtkins> fantasai: so the resolution could be that animations and transitions aren't supported on non-tree-abiding<br> <TabAtkins> flackr: safari today does support *animations* on them<br> <TabAtkins> fantasai: so MAY support, optional?<br> <TabAtkins> flackr: maybe yeah. transitions is the tricky one, need to figure out when it happens. style change from an ancestor, or just from the pseudo itself? complicated. didn't test if safari supports them.<br> <TabAtkins> fantasai: I think if you have an El and it's transitioning, the child functionally transitions due to inheritance but isn't considered to be transitioning<br> <TabAtkins> fantasai: think it would be similar<br> <TabAtkins> flackr: so I think elika's point is every browser supports tree-abidng pseudos, so it would be good to clarify that's required<br> <TabAtkins> astearns: on the "may" thing, maybe leaving the spec saying nothing about non-tree-abiding might be better...?<br> <TabAtkins> fantasai: we're not allowing "whatever". I think we can specify... if there's details like what rob mentioned we can clarify them<br> <TabAtkins> fantasai: conflicts would be on certain non-tree-abiding ones. but to the extent that impls can figure it out for some, we should allow it<br> <TabAtkins> fantasai: so I think we should be clear - a&t are allowed on pseudos, but for non-tree-abiding they're optional<br> <TabAtkins> fantasai: so impls might be a ble to figure it out for highlights but not first-letter or wahtever<br> <TabAtkins> fantasai: these are a progressive enhancement, I think it's okay to be optional<br> <TabAtkins> q+<br> <TabAtkins> astearns: I agree if optionality is meant to be a temp stopgap<br> <TabAtkins> astearns: if there's a plausible way forward<br> <TabAtkins> fantasai: I think in an ideal world we should get there<br> <fantasai> scribe+<br> <TabAtkins> fantasai: but if someone is really excited about getting ::first-letter implemented, they should go for it<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: wrt optional and progressive enhancement, I agree about transitions being an enhancement. Let's nail down details.<br> <fantasai> TabAtkins: Don't agree for animations. They are often not a progressive enhancement, can break content if they don't work.<br> <fantasai> TabAtkins: I think for non-tree-abiding, we should take a definite yes/no on animations<br> <fantasai> TabAtkins: and I would lean towards yes<br> <fantasai> TabAtkins: because theyr'e simpler<br> <fantasai> TabAtkins: but leave them unspecified now<br> <TabAtkins> astearns: but if we have a yes on animations, we run the risk on the spec being fiction since it doesn't seem to be a priority<br> <fantasai> astearns: But if we have a yes on animations, we run risk of spec being fiction, since not a priority or easy to add to engines that don't support<br> <TabAtkins> TabAtkins: wk supports animations right now, sometimes only one browser supports a feature for a while, that's fine<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: for animations on content generally I agree, but for non-tree-abiding pseudos which are very limited, I don't think I agree. a shimmery highlight or something<br> <fantasai> TabAtkins: If you set an animation to make shimmery, need to make sure you have base styles that are readable.<br> <fantasai> TabAtkins: Authors will assume animations exist, and not have good base styles<br> <fantasai> TabAtkins: So worried about that<br> <TabAtkins> fantasai: do authors in the room have an opinion on that?<br> <romain> q+<br> <TabAtkins> flackr: for the other point, we do have things that are specified but not supported in all browsers yet. i'm okay with that. we're clearly not opposed to the behavior<br> <astearns> ack romain<br> <TabAtkins> romain: as an author i've never written fallbacks for an animation not working, so I agree with Tab that it could be bad<br> <TabAtkins> romain: it's fine if an animation doesn't play and just skips to the end, but it should *work*<br> <fantasai> TabAtkins: Let's spec that animations and transitions work on all tree-abiding<br> <fantasai> TabAtkins: On non-tree-abiding, animations work, and transitions are intentionally optional right now.<br> <TabAtkins> astearns: i'm fine with that, but it does somewhat go against the idea that authors will write animations that work fine in WebKit and fail in other engines<br> <fantasai> TabAtkins: That happens with plenty of properties that are supported in one browser and not others.<br> <fantasai> TabAtkins: We prefer wide support.<br> <fantasai> TabAtkins: I think it's fine as a temporary state of affairs, to have things be in one browser<br> <fantasai> TabAtkins: OK for browser to go ahead of each other in various ways<br> <TabAtkins> astearns: so we have two proposed resolutions, for tree-abiding and non-tree-abiding<br> <TabAtkins> astearns: any tweaks to those?<br> <TabAtkins> astearns: objections to the resolutions in IRC?<br> <TabAtkins> RESOLVED: animations and transitions work on all tree-abiding<br> <TabAtkins> RESOLVED: On non-tree-abiding, animations work, and transitions are intentionally optional right now.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12814#issuecomment-4040525212 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 March 2026 16:37:20 UTC