11

I thought the whole point of this was to remove JavaScript? There’s already a working JavaScript setup to make the title heading stay on the page as the article scrolls; there’s little reason to change that if a CSS-only solution isn’t viable.

FWIW, I quickly brought up the inspector and added position:sticky;top:0 to div.header and it more or less worked. There would need to be a background set (it’s transparent right now) and perhaps a bottom border, but otherwise it looked fine and worked. I’m used CDM without expanded articles.

12

what, header transparency? it’s the

 div.cdm.expanded div.header {
-       background : transparent ! important;
+       background : @default-bg ! important;
 }

this is just for drop shadow, there’s no ugly tracking of offsets to actually show/hide the element and, more importantly, reprogram its contents to point to a relevant article.

take a look at updateFloatingTitle().

13

btw, headline scroll handler should also benefit from the observer, because currently to figure out what’s above the viewport you need to count headlines from the beginning of the buffer, etc. this seems like a good find, at first glance.

14

i was bored so here’s a proof of concept

intersection.diff (4.6 KB)

e: sorry for trying to steal your show @ctag :slight_smile:

15

That diff works well on my end. The javascript turned out a lot cleaner than my kneejerk assumption thought it would.
With articles not auto-expanded in preferences the background is still transparent though.

No worries!

e: wait, I didn’t regenerate some of the css files.

16

you’re right about .expandable, i always forget it exists.

17

revised diff intersection.diff (10.1 KB)

there’s a weird non-zero scaling effect, i.e. transparent part above the floating title.

scaling

other than that, it seems to work properly. i’m very glad we could ditch updateFloatingTitle() altogether thanks to @ctag for position : sticky.

e:

05hORhgU
05hORhgU821×142 75.5 KB
now with backdrop blur :slight_smile:

18

That diff works well for the couple things I could think to try on my end. I dig the blur too.

I’m not seeing the transparent part here in Firefox.
image

Yay!

19

i think this is some kind of hidpi-scaling-related issue. could be chrome specific, too.

if nothing comes up, i’m gonna commit this to trunk tomorrow. would be nice if others tried this diff too.

21

thanks for testing!

well, this is in trunk now: https://git.tt-rss.org/fox/tt-rss/commit/7adbc95acc4b2677be3a1d830c69b892f77d2465

22

Just updated in trunk and the changes look and feel great! The scrolling is noticeably smoother and looks better on the combined view compact theme.

Thanks guys @fox & @ctag

23

Just a quick note, this change seem to have “undone” the work on releasing the content, as now all videos, at least gyfcat, are loading and running as soon as the view is loaded and keeps playing even after the video has been read.
I didn’t have the don’t auto play html5 videos enabled, which is how I noticed the random music playing, enabling the plug-in stops the music…

24

you’re right, unpack observer should only work in expanded mode.

https://git.tt-rss.org/fox/tt-rss/commit/a1ffc116196e023491ff2c3c7b24f48924ea4fd1

in expanded mode though some articles are unpacked on load, but not all. this seems to work properly.

25

I really like this change. It’s minor but makes for a much better user experience.

One thing I noticed while fixing a separate issue is that when scrolling in combined display mode without expanded articles, the [stuck] CSS effects are applied to headlines that are already read but not expanded. This is noticeable when scrolling a long list of read articles (e.g. Recently read feed) as you’ll see the top-most headline flicker white and have a thicker bottom border just before it scrolls out of the viewport.

I’ve put together a PR that I think fixes the issue. It moves the [stuck] CSS to only apply to div.cdm.expandable.active .header[stuck] and div.cdm.expanded .header[stuck]. This seems to fix the issue I described without breaking anything else. It also seems to removes the need to override the background to transparent for expanded articles because the new directives are more specific.

26

merged, thanks!

/20char

27

I am using v20.05-eae7961 with Chrome 81.0.4044.138.

I am in combined mode and use either “n” or “Ctrl+Down” to scroll articles. Sometimes I have to press “p” or “Ctrl+Up” twice to go to the previous articles.

I could not figure out if it depends on the lenght of the articles (previous, current or following). Seems like random.

Is it just me?

28

yeah, I’ve also noticed this.

29

Maybe I am wrong, but if the current article is “pure text” (has no media, images or video of any kind), you need to press twice to go to the previous one.

30

it’s a pixel offset issue somewhere. ‘p’ currently goes to beginning of current article if it starts offscreen and to the actual previous article if it’s not.

there should be a safe zone of a few pixels in there.

31

hopefully this should help: https://git.tt-rss.org/fox/tt-rss/commit/05a84ab778ee0bc5af3ee626ef87a2074d06c51a

spent an hour on a rather exciting journey into ridiculous scrolling-related bugs in microsoft chromeedge

then i opened google chrome and things immediately became less confusing

what i’m saying here is that i feel for people who do frontend for a living