Improvents for VP animations

Hey Guys.

With Enter viewport to start an animation. We have no way of controling opacity as it enters the VP. All items have an opacity of 1. It then enters the VP, you see the item, then Bricks adds the animation class which fades from 0 to 1. So we see a flash of content before the animation.

A simple solution woud be to add a data attribute ā€˜data-brx-in-vp’ wich is added or removed as it enteres the VP. That way we can optionally set .brx-animated:not([data-brx-in-vp]) opacity to zero. I think that will prevent the flash of conttent before the animation starts.

Also, an index on items that enter the VP would be useful for staggering animations.

See this explanation.

2 Likes

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.

  1. 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.

  1. 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

Your strucuture panels looks awesome, which plugin you are using for that?

Hey. I have created my own plugin called BRXProd.

It stared as a small project and turned into a huge one with a lot of builder features.

It has a free version with:

  • HTML Tag Selector
  • AutoBEM creation, renaming, auditing etc.
  • Content Debugging
  • Bricks Wirerame framework converter, which organises the framework and uses proper scale features, + a few other things.

The paid versions have a lot more featues. I have included Documentation in th eplugin, but I really need to make time to create proper explainer videos.

I will be officially releasing it next month. I can’t do so now because I’m on a European holiday and would not be able to provide proper support.

Also, the website still needs a lot of work and updating with new and changed features.

You can get it here Pricing - BRX Productivity , either the free version or early adopter (beta) discounts for the paid versions.

I have to say, the most powerful features are in the CSS Panel and Detachable CSS Panel. I have spent many many hours on this and I’m still improving it. It is however in the paid versions.

Would love to see this implemented!
Ive cheated this with some VP animations by hiding the element when CONTENT LOADED, then add the second interaction of SHOW ELEMENT, and the animation sequentially at ENTER VIEWPORT. This seems to work…at least im not seeing the initial opacity=1 flash. Now, i haven’t really tested that on slower connections…in theory, i’d think you should still be seeing the flash.