Date and user have to be always printed on top of chat log

[iav]

Currently no date printed on a chat screen if no date change record located on a screen.
I think a date of a first line of text should always be printed on top of a chat log.
like
++++++ 25/11/2022 +++++
14:15 user: hello!

Same for a user: currently no username printed on a screen if there a wall of text typed by one user.
On a screenshot, area on a red owal – no user who typed text, no text date on screen.

[lukebarnard1]

Hi @iav, this is certainly the plan

A similar issue relating to this is https://github.com/vector-im/riot-web/issues/3756

Let's use this issue to track "Sticky room headers and sticky user avatars in the timeline"

[uhoreg]

Sticky avatars is #3902. @lukebarnard1: can that issue be closed in favour of this one?

[lukebarnard1]

@uhoreg no harm in tracking them separately and using this to track both, I reckon

[ara4n]

Looks like @lukebarnard1 had a go at this in #4939 which had to be reverted in #4991 as the implementation is not ideal: it looks to try to constantly override the header offset onScroll rather than toggling position: absolute like the current LeftPanel sticky headers code does. This causes ugliness like https://matrix.org/_matrix/media/v1/download/matrix.org/TPJuebYDhmmHRqgBiychJGhR as well as needlessly chewing CPU (and the last thing we need is things slowing down further).

Other thoughts:

• It also chews vertical real-estate, which I am not a fan of
• i would suggest hiding it if the date is 'Today' (fading it in & out).
• It's also worth noting that the hoverovers on the timestamps already include a date for disambiguation, and so we might want to make this a configurable setting for folks who don't want to waste vertical estate on it.
• this is probably orthogonal to the sticky avatar problem, which could be solved by setting the avatar/date to be position: absolute for the topmost event tile if it's starting to scroll off the top... irrespective of the presence of a sticky date bar.

Our prioritisation is all over the shop here: i thought element-hq/element-meta#1230 is P4; tom thought #3902 is P2 and luke thinks this one is P1.

The fact we've ended up with overlapping bugs is also non-ideal, although given all of them now have useful info i guess we keep them all for now (although I'd prefer to have closed this one).

[ara4n]

(also, this issue is way way lower priority than communities/groups/flair imo).

[lukebarnard1]

luke thinks this one is P1.

I'm not sure what I was thinking on that, but seemingly I felt it was p1 and I certainly don't in hindsight. This was more of a "Friday afternoon feature" that I wanted PR instead of leaving to gather dust.

[MadLittleMods]

Closing in favor of #7575