This is really cool, I love seeing folks use CSS in clever ways. :)
My one feedback would be to avoid using attr selectors on the style attribute like [style*="--lqip:"]. Browsers normally lazy compute that string version of the style attribute [1], but if you use a selector like this then on every style recalc it'll force all new inline styles (ex. element.style.foo = bar) to compute the string version.
Instead if you use a separate boolean attribute (or even faster a class) it'll avoid that perf foot gun. So write <div lqip style="--lqip: ..."> and match on that.
It's obviously mostly an aesthetic nitpick for this blog post specifically and not the project itself, because few people are going to be exploring the encoded space outside of the blog post, but the sliders letting you explore the LQIP space would "flash" a lot less if the base color was encoded in the high bits instead of the low bits.
Since there're independent Lightness values set for each section (I'd say quadrant but there are 6 of them), I wonder if two bits can be shaved from the `L` value from the base color. It'd take some reshuffling and might not play well with color customization in mainly flat images, but I think it could work.
I'm also curious to see that they're doing solely grayscale radial gradients over the base color instead of tweaking the base color's `L` value and using that as the radial gradient's center, I'd imagine you'd be doing more math that way in the OKLab colorspace which might give prettier results(?).
Tempted to play around with this myself, it's a really creative idea with a lot of potential. Maybe even try moving the centers (picking from a list of pre-defined options with the two bits stolen from the base color's L channel), to account for varying patterns (person portraits, quadrant-based compositions, etc).
Was expecting the common "background-image: data url + filter: blur" that a lot of static site generators produce, not a binary encoding algorithm implemented in CSS! Very impressive.
I wonder what other things could be encoded this way. Those generic profile pictures, perhaps? (The ones where your email or account id is hashed to produce some unique geometric pattern.)
Something to note is that Color Theif (Quantize) is using median cut on RGB, it would be interesting to try and extract dominant color in OKLab instead.
I also love the idea of a genetic algorithm to find an ideal match for a given image; it should be possible to simulate radial gradients server & client side with webgpu, but probably overkill for such a simple task.
EDIT: Although it works for me in Chrome, it doesn't seem to work in Safari v16.1.
Just in case anyone also misses it like I did, dark reader (at least on firefox) appears to apply itself to the final colors causing them to look quite bad and not match the input image at all. I would have discounted this entirely if it wasn't for all the praise I was seeing in the comments here.
Forgive my ignorance, feel like it's embarrassing to ask here to be honest, but can someone explain how this helps/works? I've never actually used these placeholders, but I always imagined that they work by processing the image beforehand on the server and using something like a super low quality image or gradient or such as the placeholder. If this is done in pure CSS, does the browser not need to download the image first to figure out what's in it, before then doing the placeholder effect? Perhaps it doesn't help that I've not had my morning coffee yet, but I don't understand.
These placeholders are generated by processing the image on a server beforehand. Generally they create some html, css or svg markup that is served inline. Having to do a separate request for such placeholder is very bad idea.
It's not clear if these placeholders do actually help, especially placeholders with very low quality. In my opinion, they only add visual noise.
I'd focus more on avoiding layout shifts when images load, and serving images in a good format (avif, webp) and size (use `srcset` or `<picture>`).
> It's not clear if these placeholders do actually help
Well, it depends what you mean by help. It’s very dependent on use case and desired UX. Obviously you can prevent layout shifts without them, you can provide feedback on loading status in other ways, and ensure images don’t slow load time without colored placeholders. But they can provide a pleasant UX for some use cases, when done right. They can be annoying when not done well.
This is really cool, I love seeing folks use CSS in clever ways. :)
My one feedback would be to avoid using attr selectors on the style attribute like [style*="--lqip:"]. Browsers normally lazy compute that string version of the style attribute [1], but if you use a selector like this then on every style recalc it'll force all new inline styles (ex. element.style.foo = bar) to compute the string version.
Instead if you use a separate boolean attribute (or even faster a class) it'll avoid that perf foot gun. So write <div lqip style="--lqip: ..."> and match on that.
[1] https://source.chromium.org/chromium/chromium/src/+/main:thi...
see also the author's last note on the upcoming parsing feature of `attr()`, which would solve both problems (performance and verbosity) at once:
It's obviously mostly an aesthetic nitpick for this blog post specifically and not the project itself, because few people are going to be exploring the encoded space outside of the blog post, but the sliders letting you explore the LQIP space would "flash" a lot less if the base color was encoded in the high bits instead of the low bits.
Since there're independent Lightness values set for each section (I'd say quadrant but there are 6 of them), I wonder if two bits can be shaved from the `L` value from the base color. It'd take some reshuffling and might not play well with color customization in mainly flat images, but I think it could work.
I'm also curious to see that they're doing solely grayscale radial gradients over the base color instead of tweaking the base color's `L` value and using that as the radial gradient's center, I'd imagine you'd be doing more math that way in the OKLab colorspace which might give prettier results(?).
Tempted to play around with this myself, it's a really creative idea with a lot of potential. Maybe even try moving the centers (picking from a list of pre-defined options with the two bits stolen from the base color's L channel), to account for varying patterns (person portraits, quadrant-based compositions, etc).
Was expecting the common "background-image: data url + filter: blur" that a lot of static site generators produce, not a binary encoding algorithm implemented in CSS! Very impressive.
I wonder what other things could be encoded this way. Those generic profile pictures, perhaps? (The ones where your email or account id is hashed to produce some unique geometric pattern.)
Really like this, nice work!
Something to note is that Color Theif (Quantize) is using median cut on RGB, it would be interesting to try and extract dominant color in OKLab instead.
I also love the idea of a genetic algorithm to find an ideal match for a given image; it should be possible to simulate radial gradients server & client side with webgpu, but probably overkill for such a simple task.
EDIT: Although it works for me in Chrome, it doesn't seem to work in Safari v16.1.
Just in case anyone also misses it like I did, dark reader (at least on firefox) appears to apply itself to the final colors causing them to look quite bad and not match the input image at all. I would have discounted this entirely if it wasn't for all the praise I was seeing in the comments here.
Forgive my ignorance, feel like it's embarrassing to ask here to be honest, but can someone explain how this helps/works? I've never actually used these placeholders, but I always imagined that they work by processing the image beforehand on the server and using something like a super low quality image or gradient or such as the placeholder. If this is done in pure CSS, does the browser not need to download the image first to figure out what's in it, before then doing the placeholder effect? Perhaps it doesn't help that I've not had my morning coffee yet, but I don't understand.
These placeholders are generated by processing the image on a server beforehand. Generally they create some html, css or svg markup that is served inline. Having to do a separate request for such placeholder is very bad idea.
It's not clear if these placeholders do actually help, especially placeholders with very low quality. In my opinion, they only add visual noise.
I'd focus more on avoiding layout shifts when images load, and serving images in a good format (avif, webp) and size (use `srcset` or `<picture>`).
> It's not clear if these placeholders do actually help
Well, it depends what you mean by help. It’s very dependent on use case and desired UX. Obviously you can prevent layout shifts without them, you can provide feedback on loading status in other ways, and ensure images don’t slow load time without colored placeholders. But they can provide a pleasant UX for some use cases, when done right. They can be annoying when not done well.
Here's the server-side (Node.js) build script that calculates the integer placeholder image values and adds them to the document: https://github.com/Kalabasa/leanrada.com/blob/7b6739c7c30c66...