This twitter thread reports an issue with animating an <integer> custom property and codepen that reduces it somewhat: https://codepen.io/jh3y/pen/vYyxoPr. We have testing coverage for <integer> animation so I expect it's not strictly an animation issue, it could be something related to `counter-reset` or `content: counter(ms)` which are also used in the demo.
Inspecting the page, I think there's no trouble actually animating the --milliseconds value since I see it changing every time I call getComputedStyle($0).getPropertyValue("--milliseconds"). Additionally, the first time I open Web Inspector after launching Safari and loading the demo, I see the counter value change to a different value each time. I expect this is indeed an issue with `counter()`.
Created attachment 465629 [details] Test
When we hit RenderTreeUpdater::GeneratedContent::updatePseudoElement() the call to Style::determineChange() returns Style::Change::None and we fail to call updateStyleForContentRenderers() as required. This is not related to animations at all, this is also an issue when changing the style through other means.
Actually, the issue goes away if we remove the `position: absolute` style in `.counter:after`.
Created attachment 465630 [details] Reduced test
Using the reduction, I can notice a difference under RenderBlockFlow::layoutModernLines() where in the good case (no position style set) the first call to modernLineLayout() returns false and where in the bad case (`position: absolute` is set) it returns true. Cc'd Alan who might know more as a layout expert.
Created attachment 465649 [details] [fast-cq]Patch
Committed 262269@main (1b539330d2ad): <https://commits.webkit.org/262269@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 465649 [details].
<rdar://problem/107363679>