Diagnosing the 5px "jump" on the inline text demo

[samselikoff]

I'm having trouble figuring out why there's a ~5px "jump" on the inline-text demo. I've been looking at the moving-word component from the Living Animation talk as well and can't figure out what's going on.

• Sometimes animated-orphans is put in a position: absolute or position: fixed div. I've tried different combinations of these but no luck. How does the position of animated-orphans affect the orphans it renders?
• I've tried "eating" all the white spice with the ~ helper
• I've experimented with different styles on <AnimatedContainer>, like inline-block and align-top

Any ideas or pointers on what's going on?

[samselikoff]

In my example here adding sprite.translate(0, -4); "fixed" the issue. I'm unable to figure out where the 4px number is coming from, even by pausing the animation & inspecting the DOM.

[chrism]

Just seen this on email and haven’t checked the code but the 4px and inline-block sound familiar. Could it be something to do with this issue? https://css-tricks.com/fighting-the-space-between-inline-block-elements/ <https://css-tricks.com/fighting-the-space-between-inline-block-elements/> Just a thought.

…

On 10 Mar 2019, at 12:43, Sam Selikoff ***@***.***> wrote: In my example here adding sprite.translate(0, -4); "fixed" the issue. I'm unable to figure out where the 4px number is coming from, even by pausing the animation & inspecting the DOM. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#76 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACKoD7hmq_wPHoIM8RPjpnKD6aQhN7fks5vVO_qgaJpZM4bnNge>.

[samselikoff]

I've managed to use some escape hatches to get the animation working, which I'd like to post here both to share, and to get any feedback on in case there are better ways to use the Sprite APIs as escape hatches in situations like this. (i.e., how would you solve this problem?)

Original transition:

transition: function*({ sentSprites }) {
  sentSprites.forEach(sprite => {
    move(sprite);
    adjustColor.property('color')(sprite);
  });
}

Updated transition:

transition: function*({ sentSprites }) {
  sentSprites.forEach(sprite => {
    if (sprite.initialBounds.top === 4) {
      let { left: initialLeft, top: initialTop } = sprite.absoluteInitialBounds;
      sprite.startAtPixel({ x: initialLeft, y: initialTop - 4 });
    }

    if (sprite.finalBounds.top === 4) {
      let { left: finalLeft, top: finalTop } = sprite.absoluteFinalBounds;
      sprite.endAtPixel({ x: finalLeft, y: finalTop - 4 });
    }

    move(sprite);
    adjustColor.property('color')(sprite);
  });
}

I tried to do some sort of this.set('isAnimating', true) logic and only apply the -4 adjustment but couldn't find a good way to do that.

[ef4]

Sometimes animated-orphans is put in a position: absolute or position: fixed div. I've tried different combinations of these but no luck. How does the position of animated-orphans affect the orphans it renders?

The important thing about animated-orphans is that it must not itself move relative to anything else during the animations. The normal way to achieve that is to put it high up in the application.hbs route. In the tests, it appears below the QUnit output, which can cause it to bump downward, which messes things up. So in the tests we sometimes need to manually make sure it doesn't move when QUnit output gets taller.

One of the most likely culprits for a vertical jump like this is margin collapse. ember-animated tries to predict margin collapse automatically so you don't need to deal with it, but it's quite possible you've found a case we don't do correctly.

There are only a small number of places in the code that are likely to be responsible for the jump. I would especially look at Sprite's lock and unlock methods. If you step through those you may be able to confirm that the jump happens inside those. If so, then you can dissect in detail what is changing in the DOM.

[qpowell]

In my example here adding sprite.translate(0, -4); "fixed" the issue. I'm unable to figure out where the 4px number is coming from, even by pausing the animation & inspecting the DOM.

Could it be coming from findOffsets in

ember-animated/addon/-private/sprite.js

Line 1005 in a0180f7

function findOffsets(element, computedStyle, transform, offsetSprite) {

?

In the inline-text demo, this would play out like this:

// findOffsets
console.log(ownBounds.top) // 34

//...

if (effectiveOffsetParent) {
  //...
 if (eopComputedStyle.position !== 'static' || eopComputedStyle.transform !== 'none') {
  let eopBounds = effectiveOffsetParent.getBoundingClientRect(); 

  /**
   * eopBounds:
   * {
   *   "x": 292.859375,
   *   "y": 30,
   *   "width": 87.25,
   *   "height": 26,
   *   "top": 30,
   *   "right": 380.109375,
   *   "bottom": 56,
   *   "left": 292.859375
   * }
   */

  left -= eopBounds.left + parseFloat(eopComputedStyle.borderLeftWidth);
  top -= eopBounds.top + parseFloat(eopComputedStyle.borderTopWidth);  // top = 34 - 30
 }
}

findOffsets gets called in the constructor via _rememberPosition -> _lazyOffsets -> findOffsets if the lockMode is position

[samselikoff]

I've since managed to fix this by making these inline elements inline-block. I noticed the Vue animation docs mention this as well:

It might not be anything we can work around in the library – the advice might be that you need to always use inline-block.