- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 17:43:01 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposal: CSS Text Transitions & Animations`.
<details><summary>The full IRC log of that discussion</summary>
<Rossen> Zakim, open queue<br>
<Zakim> ok, Rossen, the speaker queue is open<br>
<TabAtkins> kbabbitt: basic problem i'm looking to solve is being able to do aniamtions/transitions at sub-element level<br>
<TabAtkins> kbabbitt: becom epopular with some streaming text interfaces<br>
<TabAtkins> kbabbitt: or loading animations with a shimmer effect<br>
<TabAtkins> kbabbitt: authors have done this by dividing all the content into spans<br>
<TabAtkins> kbabbitt: not great for perf, lots of excess style calc<br>
<TabAtkins> kbabbitt: not good for a11y<br>
<TabAtkins> kbabbitt: would be simpler for authors to have a few simple properties that achieve these effects<br>
<TabAtkins> kbabbitt: alan pointed out this is a lot of work, yehonatan pointed out proposals for some of these things<br>
<flackr> q+<br>
<TabAtkins> kbabbitt: specifically grouping effects on element-by-element basis and sequencing these things<br>
<TabAtkins> kbabbitt: syncing and choreographing animations<br>
<TabAtkins> kbabbitt: can start with those<br>
<TabAtkins> kbabbitt: need a few pieces still<br>
<TabAtkins> kbabbitt: ref boxes for positional animations.<br>
<TabAtkins> kbabbitt: transforms, if you blockify they're animating relative to the postiion of their block not their original position<br>
<TabAtkins> kbabbitt: another, implicit assingment of group effects<br>
<TabAtkins> kbabbitt: proposal was assinging ordinals to these elements<br>
<ydaniv> q+<br>
<TabAtkins> kbabbitt: would b enice to say "all of my children, assign everyone this animation"<br>
<TabAtkins> kbabbitt: and the other effect is some way to segment text<br>
<TabAtkins> kbabbitt: i don't want to get into a world where we're addressing text uinits with selectors. back where we started with style expense<br>
<florian> q+<br>
<TabAtkins> kbabbitt: so think we need some way of talking about text more generally that just applies transforms or animations<br>
<TabAtkins> kbabbitt: addressing some issues, nested elements<br>
<TabAtkins> kbabbitt: want animations to apply thru descendent elements to all text bits<br>
<TabAtkins> kbabbitt: mutations of the text while animation is in progress...<br>
<lea> q?<br>
<lea> q+<br>
<TabAtkins> kbabbitt: appending content is easy enough, replacing is trickier<br>
<TabAtkins> kbabbitt: i'd probably just treat as a brand neew anim<br>
<TabAtkins> kbabbitt: qs about generated content, and animation/transition events<br>
<TabAtkins> kbabbitt: i think for compat sake we keep the events firing<br>
<TabAtkins> kbabbitt: they'll fire at the end of all the text units<br>
<TabAtkins> kbabbitt: so want to hear about concerns, if we're in the right direction, etc<br>
<Rossen> ack flackr<br>
<TabAtkins> flackr: we already have pseudo-elements for some pieces of text, ::first-letter/::first-line, etc<br>
<TabAtkins> flackr: have you thought thru those? havne't considered expense<br>
<TabAtkins> kbabbitt: expense is my main concern<br>
<TabAtkins> kbabbitt: avoid ahving to do a full cascade, like ::nth-word(). even in non-animation potentially v expensive<br>
<astearns> q+<br>
<Rossen> ack ydaniv<br>
<TabAtkins> ydaniv: i gave a few comments in the issue.<br>
<TabAtkins> ydaniv: like kevin said, regarding sync/staggering/sequencing, i think it's something we want to solve more generally for animations<br>
<TabAtkins> ydaniv: nothing currently regarding transitions, but we probably want to solve it there as well<br>
<TabAtkins> ydaniv: regarding targeting text parts. all these libraries today split the text (hopefully with Intl.segmenter)<br>
<TabAtkins> ydaniv: and then they wrap each part in a span<br>
<TabAtkins> ydaniv: then make it inline-block<br>
<TabAtkins> ydaniv: need to blockify everything so you get transforms<br>
<TabAtkins> ydaniv: if we want to solve these effects we need to somehow blockify the components. then can do something like what rob suggested, have a way of targetting these parts<br>
<TabAtkins> ydaniv: i know webkit jsut released a new inline-block engine<br>
<fantasai> no, it was new implementation of block-splitting-inline-boxes code ...<br>
<TabAtkins> ydaniv: i suggested something in the issue something like 'will-change:text-effects'<br>
<fantasai> much less interesting :)<br>
<TabAtkins> ydaniv: something that authors will use sparingly and UAs can maintain. if it's overused, maybe something the UA can control<br>
<Rossen> ack florian<br>
<TabAtkins> florian: havne't thought deeply, but i like the concept<br>
<TabAtkins> florian: from i18n pov, there's considerable variation about letter vs word, especially word<br>
<TabAtkins> florian: but word in english, chinese, japanese, thai all different. probably want to set it up so authros don't have to think too hard.<br>
<TabAtkins> florian: a bunch of langs have space-seaprate words, not all. thai space-separates setnences, don't wnat to get sentences when you say "word"<br>
<TabAtkins> florian: "word-level" is tricky but useful. do we want to spend time deffining this well, or is it too complex?<br>
<TabAtkins> kbabbitt: one other reason i think about it this way, layout engine alreayd needs to know graphemes, ligatures, word breaks, line breaks<br>
<TabAtkins> kbabbitt: so i'm hoping by using a higher-level concept we can just reuse that logic<br>
<Rossen> ack lea<br>
<ntim> p<br>
<ntim> p+<br>
<TabAtkins> lea: to florian, there is Intl.segmenter, UA already has these mechanics and exposes it to authors. presumably would do the same<br>
<TabAtkins> lea: for transofrm effects, was mentioned it need to be blockified. a lot of effects weren't using transofrms, today could use highlight API, doens't need blockification<br>
<castastrophe> florian: what would you think about alternative naming like “chunk” or “set”?<br>
<TabAtkins> lea: am wondering if we can reduce the number of primitives, complexity is a common complaint<br>
<fantasai> s/florian:/florian,/<br>
<TabAtkins> lea: there is precedent today where we have pseudo-elements restricted to an allowlist of props<br>
<TabAtkins> lea: wonder if it would alleviate perf concenrs to heavily limit the props allowed<br>
<TabAtkins> lea: would be more extnesible in the future, while new primitives require us to edit the feature when we want to do mor epowerful<br>
<TabAtkins> q+<br>
<Rossen> ack astearns<br>
<TabAtkins> astearns: i don't like thi sproposal, animating text is wrong and you shouldn't do it<br>
<romain> +1<br>
<TabAtkins> astearns: i do worry we could get into a sitaution where we're chasing a popular effect, and by the time it's specified/implemented the effect will be out of vogue<br>
<TabAtkins> astearns: i did mention in the issue we should talk to the people with those libraries, might be low-hanging fruit that could make their scripting solution better<br>
<ydaniv> +1 to astearns but I think text effects in general have been around for quite a while (:<br>
<Rossen> ack fantasai<br>
<Zakim> fantasai, you wanted to point at fill-stroke<br>
<fantasai> https://drafts.csswg.org/fill-stroke/<br>
<TabAtkins> fantasai: there is a fill-stroke spec that hans't seen much attention but would allow for some of the animation effects<br>
<TabAtkins> fantasai: allows image fills, etc. might address some use-cases<br>
<Rossen> ack TabAtkins<br>
<ntim> brain dumping an idea: `text-effect: name 0.3s ease;`, `@starting-style { p::text-effect(name) { transform: scale(0); } }`<br>
<fantasai> TabAtkins: Multiple people talked about :nth-word. I agree with kbabbitt, even if there weren't perf issues, I think the usability of the feature is better by having a dedicated system<br>
<fantasai> TabAtkins: because of cases like appending vs adding, etc. We can't address in selectors.<br>
<fantasai> TabAtkins: but a UA could handle how it wants to do all the animations in these cases<br>
<fantasai> TabAtkins: So if we want to do this feature, it is best done with a special-case word animator, not via generic animations + pseudos<br>
<Rossen> q?<br>
<TabAtkins> (not disagreeing with what Tim just suggested, fwiw)<br>
<TabAtkins> arronei: not disagreeing with Alan that the effect might be overused currently. but think we should continue with it to see what problems we run into<br>
<TabAtkins> arronei: as we do, should make very careful to consider intl text. probably where we'll hit the most problems, not necessarily from impl concerns but from a user<br>
<Kurt> prefers-reduced-motion should respect this, which should address a lot of concerns<br>
<TabAtkins> +1 to Kurt<br>
<TabAtkins> astearns: one comment on pref for solution that doen't use ::nth-word()/etc. could be fine but risks getting half the use-cases, but other half can't be extended to fit. so some amount of plumbing needs to be exposed, i think<br>
<TabAtkins> Rossen: Hearing interest and concerns<br>
<TabAtkins> Rossen: were you looking for a resolution, or just introing the concept?<br>
<TabAtkins> kbabbitt: just presenting for now<br>
<TabAtkins> <br dur=17min><br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13689#issuecomment-4164320205 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 17:43:02 UTC