Hi team,
Iāve been working around a couple of gaps in Bricksā built-in entry animations and would love to see them solved natively. Both are small changes that would benefit every Bricks user.
- FOUC on fadeIn* animations (visible initial state)
.brx-animated is added to the element immediately on render, but the actual animation class (fadeIn, slideInUp, etc.) is only applied by JS once the IntersectionObserver fires. Because the animate.css from {} block is only active while the animation class is present, the element renders at full opacity in its final position until that class lands. On slower connections, slower devices, or when the element is above the fold, users see a flash of the final content before the fade-in actually starts. The same issue applies to slideIn*, zoomIn*, etc. ā the pre-animation state isnāt enforced on the element itself.
Ask: Apply the initial keyframe state to entry-animated elements at render time, before the animation class is added ā either via inline styles emitted on the element, or via a CSS rule keyed on a data-brx-animation attribute. The IntersectionObserver would then add the animation class as it does today, but the element would already be in its hidden/offset state from first paint, so thereās no flash.
- A native stagger index for children
Staggering a group of children (cards, list items, grid tiles) currently requires either JavaScript or nth-child CSS. The nth-child approach breaks the moment the list is dynamic, filtered, or reordered, and it caps out at whatever ladder youāve authored. Iām currently generating up to 10 nth-child rules to set a --brxp-duration per child, which works but is brittle.
Ask: When the IntersectionObserver adds the animation class to children of a parent that has a āstagger childrenā option enabled, also set a CSS custom property like --brx-entry-index: N on each child as itās processed. Authors can then write:
.my-card { animation-delay: calc(var(ābrx-entry-index, 0) * 100ms); }
This works for any number of children, survives reordering and filtering, and keeps the consumer-side code pure CSS.
Both of these would let me delete a meaningful chunk of override code and would fix a FOUC issue I think a lot of users have hit on hero sections.
I canāt include my workaround code here because the forumās rich text input mangles it, but Iām happy to share it if that would be useful.
Thanks!
Alan