Using animation css on sdc affects slot position and size

effulgentsia → credited jessebaker → .

I suspect what's happening here is that we determine all the component and slot dimensions on page load and in a resize observer, but I wonder if CSS animations interfere with that. Adding @jessebaker to this issue because he wrote most of the current code that we have for this.

I suspect this is because the animation is not actually changing the observable size of the component - it's using transform/translate etc. That means that when the animation finishes the resize observer is not fired again to recalculate the overlay sizes.

In animate-height.gif attached you can see the border is correctly tracking the size of the element (this element has a looping animation that changes the css height property.

This might be solved/improved if we also recalculate the overlay size on the animationend (and/or animationiteration) event. We already call the recalculation on transitionend in ui/src/hooks/useSyncPreviewElementSize.ts.

I've had a bit of a play around with how easy to implement this is and it's fairly trivial to get the component overlay to correctly update after the animation has finished but not so easy to trigger a recalculation of all the children (a component that animates and has a slot will fire the animation end on the component but the slot, as a child, doesn't receive that same event).

A thought I had was to have the border recalculation occur on mouseEnter of the overlay component so that even if it gets out of sync, it will 'snap' to the correct size if you attempt to interact with it. This works for components but the overlay for empty slots has pointer-events: none;. I need to investigate why that's the case.

I've pushed a slightly experimental MR. It's not optimised very well and is a bit hacky but I think the concept is along the right lines. I'll continue to work on it but thought I'd push it up asap in case you want to try it out.

Thanks a lot for the quick work in this issue, I'm offline for now, I'll check tomorrow 🙏

It looks like it's working great 🎉

Epic work on this @jessebaker 👏

Seeing the slot rendering weird

Posting the component i was testing with here:

const SpinInComponent = ({slot1}) => {
  return (
    <div className="spin-in-container">
      <div className="spin-in-box">{slot1}</div>
    </div>
  );
};

export default SpinInComponent;

.spin-in-container {
  width: 300px;
}
.spin-in-box {
  background-color: #3498DB;
  color: white;
  padding: 20px 40px;
  border-radius: 8px;
  font-size: 1.2em;
  text-align: center;
  animation: spinIn 2s ease-out forwards;
  height: 100px;
  width: 300px;
}
@keyframes spinIn {
  0% {
    transform: translateX(-100%) rotate(0deg);
    opacity: 0;
  }
  50% {
    opacity: 1;
  }
  100% {
    transform: translateX(0) rotate(360deg);
  }

I discovered if you remove the outer div to the above component, it looks like it works as expected on animationend . So maybe the problem is the border is getting recalculated using the .spin-in-container parent div position instead of the .spin-in-box inner div that the animation is actually on?

Below is GIF with the parent div .spin-in-container commented out

Seeing #15, I'm thinking that we probably should actually try to disable animations in XB instead of trying to make the UI work with them.

With 🐛 Position of some components is miscalculated frequently Active now landed the originally reported issue appears to be fixed as far as I can tell. However @lauriii in #16 you suggested that we disable CSS animations/transitions in the preview entirely.

MR!1326 disables CSS transitions and animations in the preview but, with the original issue mostly fixed, I'm unsure if you still want to go ahead with that.

jessebaker → closed merge request !1292