3 ms·
So they created a new event so people can use JS to create "reading indicators which move as you scroll." You know what else can do that? Scroll bars. In the br
by billyhoffman 3y ago
So they created a new event so people can use JS to create "reading indicators which move as you scroll." You know what else can do that? Scroll bars. In the browser. That don't disappear. Those tell you how far you are in the document as well.
- hbn 3y agoIt's hard to rely on the scrollbar if the website either loads the article as you scroll (I think Ars Technica does this) or you know whether or not there's a comments section. Or sometimes there is a comments section but it doesn't load until you scroll it into view. I find myself frequently jumping to the bottom of the article to see if the small scrollbar is due to the article length or a comments section.
- wtallis 3y agoWebsites that are doing obviously wrong things shouldn't be used to justify another layer of bad features being added. There's never any justification for deferring loading of the rest of an article until you scroll. The images, maybe, but definitely not the text.
- ComputerGuru 3y agoI don’t think the new scroll timeline fixes the lazy loading issue.
- eyelidlessness 3y agoThere are already JS solutions for scroll-based behaviors and styling (the actual scroll event, IntersectionObserver which performs better because it’s non-blocking and batched). Scroll Timeline is a CSS-only solution. And it’s kind of a misnomer, it’s really a position-based styling mechanism that can be used without any scrolling at all[1]. At minimum, this API will allow existing functionality that relies on scroll position to perform better (first by integrating with the rest of the CSS-paint pipeline, next IIUC by offloading to GPU where possible), which itself is welcome. But it also unlocks a bunch of other styling possibilities that are either impossible without JS or rather brittle. 1: https://kizu.dev/position-driven-styles/ https://kizu.dev/position-driven-styles/