Implement sticky headers using CSS

[germain-gg]

Fixes element-hq/element-web#14709
Fixes element-hq/element-web#14665
Fixes element-hq/element-web#14531
Fixes element-hq/element-web#14493
Fixes element-hq/element-web#17412
Fixes element-hq/element-web#17283

Asking for a design review by @matrix-org/design as implementing this requires us to remove the blurred background image as we need to have a background color set on the sublist header for this CSS implementation to work.
As an alternative to a solid background we could have a horizontal linear gradient.

Tested on

• Chromium
• Firefox
• Safari

Overall the scrolling experience is way smoother. Looking at the recording it can seem that we are doing more work with the JavaScript implementation, but this is purely because now the browser is able to render at a higher frame rate

Before 🐌

After 🐎

---

This PR currently has no changelog labels, so will not be included in changelogs.

Add one of: T-Deprecation, T-Enhancement, T-Defect, T-Task to indicate what type of change this is plus X-Breaking-Change if it's a breaking change.

[SimonBrandner]

Also fixes #14493

[t3chguy]

this ought to be a theme var

[t3chguy]

does this sticky both top and bottom like existing impl?

[t3chguy]

@SimonBrandner that looks like #6054 (comment)

[nadonomy]

@gsouquet since we spoke last via DM on this, did you end up finding a solution for the bottom/next section headers?

[germain-gg]

@nadonomy A full CSS solution will not be possible as the property make elements stick at the top of the visible area of the elements. However we can explore more performant ways of approaching this using an IntersectionObserver
This has been deprioritized as we were not really sure on the way forward and the implications for design

[nadonomy]

@nadonomy A full CSS solution will not be possible as the property make elements stick at the top of the visible area of the elements. However we can explore more performant ways of approaching this using an IntersectionObserver This has been deprioritized as we were not really sure on the way forward and the implications for design

@gsouquet apologies for not following up explicitly on this. When developing this version of the room list we found the bottom sticky headers were essential. Keen to not rip them out when refactoring. Thoughts:

1. Taking the above as a requirement, if you're able to reprioritise the IntersectionObserver approach, it'd be great for you to pair with @janogarcia on whatever issues you find, and I can make time to aid in support/review.
2. Room list navigation is fundamentally changing having shipped Spaces. We're expecting users to need to navigate smaller lists. We're now embarking on a project to improve the overall info architecture of the apps, which includes the room list. It's possible we might no longer need the labels, but we won't know after ideation and testing.

If the effort for 1 is low, it could be worth finish lining this PR with @janogarcia. If you'd prefer to see where arrive at with the info architecture work this quarter, we could liaise between yourself, @t3chguy & @niquewoodhouse.

What are your thoughts?