Convopage
See the entire conversation
Thanks to @cramforce's post, went down a rabbit hole to get blurry img previews but avoid layout re-raster and the SVG document costs.
Solution only needed CSS `filter`, modern `background`, & 11ty pre-build magic. Also, animates, e.g. (scroll down):
Election Season 2020, W3C TAG Edition - Infrequently Noted
It's TAG election time again, and among a packed field, a few candidates stand out. If you've benefited from the way the TAG has become a functional and important part of the W3C and broader web ecosystem process in the past several years, I heartily recommend devoting your AC rep's first place vote to Jeffrey Yasskin.
infrequently.org
21 replies and sub-replies as of Dec 31 2020
Solution does use script to prime animations (as progressive enhancement), but that's mostly to avoid issues w/ alpha and to trigger the effect when things come into view (fun?). Obviously, optional.
Posts w/ many images show it best:
infrequently.org/2020/06/platfo…
I'm still not entirely sure about the blur animation; it janks a little w/ scroll on slower devices, and haven't debugged that deeply. Might turn it off.
Highlights of this approach so far are:
- no extra SVG document
- script not required to load blur preview
- build step awareness of image alpha allows us to skip inlining thumbnails when that will look bad (no script to remove after load)
Caching image thumbnail base64 output along with dimensions at build time, and using a shortlink to keep track of images I knew I didn't have cached metadata for, also allows re-builds to skip expensive image processing. Also, works well w/ Netlify LMS + LFS.
The last bit is particularly nice; if you're using a CDN for image transforms or some other Git LFS-based solution, your final build environment might not actually have access to files on disk, but your development workstation will...
Using a shortcode/macro to create image markup allows me to track which images I've already "seen" and generated cached metadata (and previews) for, moving that to a separate build step. Don't have all the files? No crisis; it'll layout-shift until you do, but no biggie.
There's a possible optimisation w/ a second element + opacity for the animation, but at this point I'm going to wait until Paint Worklets support passing in URL-based images to get fancier.
As for potential dropped frames, it's interesting to me that this is fully on the compositor thread once the `unblur` animation starts. Maybe the answer is to delay the animation until scrolling slows/stops?
Clobbered the...
`clip-path: polygon(0 0, 100% 0, 100% 100%, 0 100%);`
...on images that fade in. Decided I like the "blur outside" effect better.
That’s a nice way of doing LQIP, even if I don’t like them… 😅
Please don’t wait for scroll to stop, as I like to scan an article with continuous scrolling, and a bunch of LQIP make me leave. 🙏🏼
I see your blog is a PWA. It might be cool if 'installing' a blog PWA could be like subscription to an RSS feed. No home screen icon, but addition to a list that I could review from time to time for a 'new content' icon.or something like that.
Excited! Have been musing on good ways to do tufte-style footnotes without having to keep them either too short or generate unhealthy markup.
Pretty cool. What aspect of this technique (without SVG) prevents the layout re-raster?
I'll write it up. @cramforce and his team noticed that some approaches had causes multiple rasters on re-layout of elements, and so were using SVG. This appears to avoid that, while also skipping SVG path.
The relayout I'm concerned with are two cases
1. size of the image changes
2. size stays the same but the container of the image needs a layout.
At least the latter should be helped by contain:strict. Not sure about (2). The most obvious way around that is to use canvas
Size changes as in responsive layout change?
For the container layout, will verify that this approach does what I hope it does.
IDK how to avoid re-raster on size change w/ a blur filter. Suspect we can't. Presumably SVG avoids by just re-setting clip on projected BG, but I imagine cases where that will fail too.
I think the key is that the intrinsic size of the SVG is invariant to the pixels painted to the screen.
Or really the size of the image inside of the SVG is, not the SVG itself.
Well, we treat the SVG *as* the image for purposes of projecting it as a BG, so as long as SVG doesn't change, it's all clip/scale ops on the compositor.
Interestingly, blur filter is now on compositor too, so difference in costs is something I'm interested in.