As far as I know, right now tt-rss uses a hide/show floating header for article titles while scrolling. This works OK, but just about every time I use my instance I think to myself “Hey, this might be cleaner with sticky positioning, and I might actually know how to do that.” and so now I’m writing this post.
Benefits to this new idea: A little bit cleaner visually, no more titles that are rendered before or after their respective articles (or maybe that only happens to me?). And the updateFloatingTitlejavascript function can either be lightened or removed altogether.
Fox: I’d like to work on this and submit a pull request. Would you be interested in merging it if I do?
I think this is a good idea. I’ve used sticky on a few other sites and it works really well.
(Plus I’ve noticed that TT-RSS can sometimes not handle returning the article heading to “normal” if the article is collapsed (combined display mode, not expanded) and the normal and stuck versions are basically in the same spot.)
I’m dumber than I look, so this might take a while.
I beat the app’s Dockerfile with a mallet until it started working as a testing environment, and got a mockup of the CSS going. Is there a less Makefile? I saw one in the git history at one point. Or do you run lessc --source-map light.less light.css for each CSS file?
The article content sliding under the header without any sort of dropshadow looks bad and confusing. Unfortunately there doesn’t appear to be a baked-in CSS solution to adjusting an element’s properties after it becomes “stuck” to the window, and a static always-on dropshadow is equally bad. I found some possible solutions:
Add a javascript event observer that adds a shadow when the article begins to scroll. I’d just rather not do this.
Cite some jank CSS magic to make a drop shadow appear on scroll with nested sticky elements. It appears to work, just is gross and I saw some demos that had become broken in newer browsers.
Add a static border to the header. It isn’t a drop shadow, but appears to look OK both before and during scrolling. And it matches the bottom border of the toolbox at the very top. I prefer this one best.
There’s also a hiccup with the header’s background. It’s set to “transparent !important;” I think because the .Selected article div behind it is changed colors on checkbox… Should the .Selected color change be moved to the .header element?
And if you want to help me sleep at night: what does “cdm” in the CSS files stand for?
I’m using phpstorm automatic less builder, vscode also has one. If you want to do it manually then it’s basically what you said.
you could use a mutation observer which would add a class name based on, something, i dunno what exactly. position in the viewport? i would rather not have a static border around all headers.
it’s hard to discuss this without some kind of proof of concept which i could screw around with in dom inspector.
combined display mode. as opposed to three panel mode.
Either way I want to fix the background transparency issues first, then we can dial in a dropshadow solution that looks good.
Yeah, it’d be great to be able to share a live example. I’m pants-on-head bad at docker, but I’ll try to get it spun up on another machine that can have a port forwarded to it.
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.
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.
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.
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.
