Low-quality image placeholders (LQIPs) have a solid place in web page design. There are many different solutions but the main gotcha is that generating them tends to lean on things like JavaScript, requires lengthy chunks of not-particularly-human-readable code, or other tradeoffs. [Lean] came up with an elegant, minimal solution in pure CSS to create LQIPs.
Here’s how it works: all required data is packed into a single CSS integer, which is decoded directly in CSS (no need for any JavaScript) to dynamically generate an image that renders immediately. Another benefit is that without any need for wrappers or long strings of data this method avoids cluttering the HTML. The code is little more than a line like <img src="…" style="--lqip:567213">
which is certainly tidy, as well as a welcome boon to those who hand-edit files.
The trick with generating LQIPs from scratch is getting an output that isn’t hard on the eyes or otherwise jarring in its composition. [Lean] experimented until settling on an encoding method that reliably delivered smooth color gradients and balance.
This method therefore turns a single integer into a perfectly-serviceable LQIP, using only CSS. There’s even a separate tool [Lean] created to compress any given image into the integer format used (so the result will look like a blurred version of the original image). It’s true that the results look very blurred but the code is clean, minimal, and the technique is easily implemented. You can see it in action in [Lean]’s interactive LQIP gallery.
CSS has a lot of capability baked into it, and it’s capable of much more than just styling and lining up elements. How about trigonometric functions in CSS? Or from the other direction, check out implementing a CSS (and HTML) renderer on an ESP32.
I bet the reason for the mystery of values getting rounded beyond 6 digits is that it is stored as 32 bit float at some point for some reason.
Lazy loading is a terrible UX, by all means we should have opted for low (maybe 70% quality) highly compressed webp/avif and then just load the original jpeg/png with 100% quality.
Also this is not about the format itself, but that blurred images really do not communicate any meaning at all. I remind the oldsters here: On the early web, did you prefer images loading line by line, or that progressive effect where the full size appears and then iteratively rasterizes from pixelated to unpixelated in multiple steps?
As an example:
[https://www.davidhboggs.com/blog/conversion-optimization/use-progressive-jpegs-to-reduce-loading-times-of-your-web-pages-2781-thread.html]
We could have just been smart with new formats: Include multiple previews with little to no overhead. In the end where you have the extra code doesn’t matter. Inside the file itself always appeared more logical to me.