This seems like the type of thing that I'd want to like. But the necessity of inline assigning the `--i` CSS variables to each element bothers me. I have to use some template system or manually keep these variables in sync in my markup. Doing those things seems worse than doing this kind of layout arithmetic in javascript, loathe though I am to admit it.

Agreed.

I just checked with some code that I wrote a while back to rotate a faux-3D pyramid, to see how I did it. The trigonometry was the easy part, it was the backface culling that was the hard part. Anyway, I decorated my elements with CSS variables in script and used lots of Math.sin/cos/tan. Also present were lots of radian conversion things and the fun that goes with animating things the 'right way'. Basically oodles of extra stuff that took me the best part of a week to do, to result in something that memory leaks if left running for a few hours.

Now I have seen this article, I might just have to mix and match JS and CSS, so I build out the elements in code and add the CSS variables to them, for everything else to be done in CSS. I will obviously need an intersection observer to trigger the CSS rather than my JS, and so it goes on!

Either way, the trigonometry is the easy part, fixing that memory leak the hard part, but CSS is the way to go because that will work perfectly, unlike with JS.

He does mention at one point that sometime soon it won't be necessary:

> Note: This step will become much easier and concise when the sibling-index() and sibling-count() functions gain support (and they’re really neat). I’m hardcoding the indexes with inline CSS variables in the meantime.

The inline links there go to https://css-tricks.com/almanac/functions/s/sibling-index/, which is pretty nifty honestly.

Inlining isn't necessarily a requirement for how it's used here. E.g. you could put something like:

  .container:nth-child(1) {--i: 1}
  .container:nth-child(2) {--i: 2}
  ...