Does the scroll behavior of the top app bar match Material guidelines?

[thanasibakis]

(Link to Material guidelines in question)

On my dashboard, the scroll effect only seems to take place once the whole view has been scrolled back to the top, and has more of a "fly in" effect than the guidelines' "compression" effect, in that it moves in after the content has reached its destination, and not with the content.

Granted, I imagine the compression effect is trickier to implement. But perhaps (in my opinion, at least) it would be cooler to adopt the "fills with contrasting color" effect listed first in the scrolling behaviors?

Thank you for your hard work on the theme overall, by the way!

[thanasibakis]

I would be happy to take a stab at the contrasting color transition, but am not sure exactly which CSS variables you would use to color the bar

[Nerwyn]

Definitely take a stab at it! I'll also take a closer look later. The header text and icons use --md-sys-color-on-surface. The header is just transparent, as it's the same color as the view background --md-sys-color-surface (we can change this to be the explicit color if it helps with the improved transition). The scroll in/out transition is top 50ms ease-in-out 0s, which I imagine is what you want to change.

The MD3 guidelines does have this section on scrolling, which mentions using a compress effect. At first glance I don't see a reference to compress in the MD3 transition guidelines but maybe it's worth a deeper read.

Currently, the header is just shifted upwards off screen when a scrolled hui-root host is detected, and a transition is used to make it appear less jumpy. The view is what is actually scrolling, but the header is outside of the view. Ideally the header would be made part of the view and scrolled naturally but most of this theme is CSS hacks to make it look like Material Design 3, not a neat proper implementation.

[Nerwyn]

I'm stumped. Because the only way we can tell if a view is scrolled is the scrolled attribute on the hui-root host, I can't find a pure CSS way to detect the amount scrolled or if the user scrolls up. I did look into switching from modifying the header top position to a transform translateY instead to at least improve performance but that messes up the footer positioning was able to improve the header scroll animation performance by switching to a transition that only affects the buttons and title.

[Nerwyn]

I've put out an alpha which improves the header scroll performance, but doesn't fix the deeper limitations that prevent implementing scroll compress behavior.

I did notice that I could do some more in depth style changes to hui-root to make the header and view not positioned absolutely, which would cause the header and view to be vertically in line and would remove the need for scroll transitions. I can play around with that later but it still doesn't fix the limitations that prevent implementing scroll compress behavior.

[thanasibakis]

Definitely looks much nicer!

One thing I'm picking up on, in the iOS app at least, is that the scrolled attribute isn't removed from hui-root until after the iOS-style page "bounce" effect that happens on swipe; thus, the top app bar doesn't reappear until the rest of the view bounces back into place, which is a bit jarring.

This is different from what I'm seeing on Chrome on macOS, where the scrolled attribute is removed as soon as the top of the view returns to the top of the page, and the top app bar bounces with the rest of the page (which looks nice).

So, the change in header positioning would probably be much appreciated 🙂

[Nerwyn]

While changing the header position seems to work okay at first, it causes a ton of headache with modals and custom cards layering incorrectly with it and the footer bar. Plus the header title (which is an ::after pseudo-element of the current view tab with fixed position) still requires the scroll animation as it isn't positioned with the header, and by making the header static it scrolls out of sync with the header title.

I've put out another alpha but it keeps the same header performance improvements as the last alpha but reverts the scroll transition speed back down to 50ms. It also includes some semi-related ha-switch and sidebar performance fixes.

I don't think there's really anything I can do to improve the the header scroll behavior past these performance improvements. We're really limited to using CSS hacks and the existence of the scrolled attribute on hui-root.

[Nerwyn]

Released 3.1.2 with header scroll performance improvements.