Animate status bar max-height and margin-top

[lukebarnard1]

When collapsed, the max-height is set to 0px. When expanded, max-height is set to 50px, margin-top is set to 0px. When expanded and when the timeline is not scrolled down to the bottom, margin-top is set to -50px to offset the change in height, keeping it at the same scroll position.

Without the animation, there would be a jump when the user starts scrolling up from the bottom whilst the StatusBar is expanded.

Complements matrix-org/matrix-react-sdk#615

[lukebarnard1]

I'm wondering whether we should animate adding event tiles to the timeline itself, or at least the sticky scroll position so that the timeline doesn't suddenly jump.

[ara4n]

(optionally) animating addition of roomtiles too would be lovely eyecandy, although i'd do it as a separate PR.

[ara4n]

this is almost perfect :D

Slightly weird things:

• The animation should probably be a bit more snappy - 200ms tops rather than 500ms
• If you're scrolled up, and someone's typing, when you scroll down to the bottom you get a weird animation transition as the bar shifts into the "stuck to bottom" mode, which makes the scrolling feel quite strange - as if there's inertia on the scroll. It's a bit of an edge case, but i wonder if we can do better...

[ara4n]

please use $primary-bg-color or whatever the variable is in our brave new SCSS world

[lukebarnard1]

Is there something I might have to merge in to get that to work? I've got npm start:css running, but it doesn't seem to be doing SCSS

[lukebarnard1]

I think this might have to be done as a separate PR because this was branched prior to scss stuff.

[ara4n]

as per main comment, suggest .2s

[ara4n]

hm. this is almost a beautiful hack, but it does result in a weird "inertial scrolling transition when you scroll from middle to bottom of timeline whilst the statusbar is visible. Feels like there should be a way to skip the transition in that scenario.

[lukebarnard1]

Using ease-out instead of ease-in-out on .mx_RoomView_statusArea seems to make this weird inertia feel less weird. Ideally we would do the transition based on the scroll position of the scroll view... or lose the _mid_timeline class earlier on.

[lukebarnard1]

or lose the _mid_timeline class earlier on.

would require some major threading-through of a theoretical isNearlyAtBottom on ScrollPanel of react sdk

[ara4n]

@lukebarnard1: is this meant to be back with me?

I was assuming that a possible correct fix for the weird scrolling would be to always have the status bar position: fixed at the bottom of the page, but animate the gap at the bottom of the screen required to house it in sync with the height of the element. So, if the statusbar is visible, no animations would be happening at all, so no scope for weird transitions when scrolling up & down the timeline?

[lukebarnard1]

@ara4n If we animate the gap at the bottom of the screen, then we change the position of events in the timeline. This is fine when we're scrolled down to the bottom but not when we're mid-timeline. So however we manage it, we have to treat being mid-timeline differently.

[ara4n]

From the files of police squad #riot-dev:

i got a solution ftr; will backlog it here for the record; no need to interrupt weekend tho
i think the correct solution is that rather than doing the negative margin-top hack on the StatusBar
you should ideally be scrolling the offset of the timeline when needed in order to compensate for the animation
so: if you are scrolled up on the timeline, and the statusbar is visible
then when the statusbar retracts, you would ideally compensate for it retracting by scrolling upwards by the same amount (as the animation progresses)
obviously this means syncing JS & CSS layout, which is pretty evil
one could make it better if the reveal/hide animation was done by JS (using velocity or whatever the post-velocity thing is that FB or someone came up with)
which should if anything be better perf than CSS anyway
so i think that'd be my recommendation in the long run
however, in the short term, i'd just ignore the problem and have the statusbar show/hide and always shift the timeline, whether at top or bottom.

[lukebarnard1]

OK, so for now we shall

ignore the problem and have the statusbar show/hide and always shift the timeline, whether at top or bottom.

This will mean removing the CSS to change margin-top

[ara4n]

lgtm!