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.
matthberg
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).
Cieric
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.
mubou
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.)
mattdesl
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.
duffyjp
Years ago before you could do anything this fancy with CSS I experimented with generating 3x2 pixel images server side and then presenting them as base64 encoded pngs in a "scoped" block of CSS to ensure they loaded before the src images. Coincidentally this was the same 3x2 layout as OP did here with CSS. I abandoned it because a 3x2 image scaled up looked terrible, and went with average color instead. This solution looks a lot better visually.
I still do the average color thing today since it's easy to calculate and store server side (I resize the uploaded image to 1x1 px and just record the result as a hex code in the DB).
emsixteen
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.
show comments
bufferoverflow
We need to embrace WebP v2 for this kind of stuff. I took one of their images, resized it to 24x16px, and compressed it with Squoosh at 65% quality. It compresses to just 144 bytes. And it looks way way way better than these CSS gradients.
I read the title as “Minimal CSS — only blurry image placeholders” first by mistake. ;)
throwaway2016a
Very nice solution!
Definitely very low resolution, but compared to sites that use a solid color this seems much better. And only requiring one variable is really nice.
The article seems very well thought through. Though for both the algorithm and the benchmark algorithm the half blue / half green image with the lake shows the limitations of this technique. Still pretty good considering how light weight it is.
show comments
chmod775
Cool hack, but performance is terrible. That page makes scrolling on my phone laggy.
turnsout
Man, it's wild how much you can do with CSS calculations. How long before someone makes a CSS-only Game Boy emulator?
thwarted
No one remembers the lowsrc img attribute.
molszanski
Amazing work! Thanks you for sharing!
biker142541
This works significantly better than I would have expected. I was just exploring extremely simple png strings as an alternative to the hash libraries requiring decoding. I had also explored two color css gradient, based on pregenerated major/minor colors, but too course to be useful (for a fast scrolling gallery). I’ll give this a test drive!
Reubend
It's a cool solution, and I like that it's CSS only. But the generated placeholders are way too blurry/lossy for my personal preferences.
Zensynthium
Love the website and article! Looks like even with CSS there's always new things to learn and do, good stuff.
cynicalsecurity
Why is the page so sluggish on mobile?
show comments
mike2323
broken on iOS (iPad)
show comments
jbverschoor
That's sexy!
dmitrygr
cool, but the fact that you can now do this with CSS is part of the reason that a new browser engine is so unlikely - one of 100000 things that css can do now and need to be supported :(
Maybe we should have kept CSS simple and JS optional. Maybe we took a few wrong turns...
show comments
davidmurdoch
This is brilliant!
seejayseesjays
this is super neat! love your site
naveed125
This is pretty neat
superkuh
I suppose the existence of bad uses does not invalidate the good but it feels like 99% of blurry image placeholder behavior is actually just preventing people from seeing anything unless they also run the ad and spying javascript that monetizes the site.
So a CSS-only way is neat and indisputably better but I think it's missing the point? The point of blurry placeholders isn't to make things easier or display better. The point is to make things worse. This write up is definitely making things better.
show comments
ipunchghosts
I know very little of css and to me it seems like a configuration file for rendering text, similar to changing default fonts ornsizes for matplotlib plots using plt.rcParams. How does this do inage blurring then?
Also a bit of nitpicking. While it provides a visual placeholder for an image that's being fetched, it does not reflect its content. So, when it's loaded we can see a completely different color palette and shapes.
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...
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).
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.
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.
Years ago before you could do anything this fancy with CSS I experimented with generating 3x2 pixel images server side and then presenting them as base64 encoded pngs in a "scoped" block of CSS to ensure they loaded before the src images. Coincidentally this was the same 3x2 layout as OP did here with CSS. I abandoned it because a 3x2 image scaled up looked terrible, and went with average color instead. This solution looks a lot better visually.
I still do the average color thing today since it's easy to calculate and store server side (I resize the uploaded image to 1x1 px and just record the result as a hex code in the DB).
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.
We need to embrace WebP v2 for this kind of stuff. I took one of their images, resized it to 24x16px, and compressed it with Squoosh at 65% quality. It compresses to just 144 bytes. And it looks way way way better than these CSS gradients.
https://squoosh.app/
Another simple css-only solution as the article mentions is gradients. Like
Tool: https://tools.w3clubs.com/gip/My attempt at the four color approach:
https://0x0.st/820Q.html
I read the title as “Minimal CSS — only blurry image placeholders” first by mistake. ;)
Very nice solution!
Definitely very low resolution, but compared to sites that use a solid color this seems much better. And only requiring one variable is really nice.
The article seems very well thought through. Though for both the algorithm and the benchmark algorithm the half blue / half green image with the lake shows the limitations of this technique. Still pretty good considering how light weight it is.
Cool hack, but performance is terrible. That page makes scrolling on my phone laggy.
Man, it's wild how much you can do with CSS calculations. How long before someone makes a CSS-only Game Boy emulator?
No one remembers the lowsrc img attribute.
Amazing work! Thanks you for sharing!
This works significantly better than I would have expected. I was just exploring extremely simple png strings as an alternative to the hash libraries requiring decoding. I had also explored two color css gradient, based on pregenerated major/minor colors, but too course to be useful (for a fast scrolling gallery). I’ll give this a test drive!
It's a cool solution, and I like that it's CSS only. But the generated placeholders are way too blurry/lossy for my personal preferences.
Love the website and article! Looks like even with CSS there's always new things to learn and do, good stuff.
Why is the page so sluggish on mobile?
broken on iOS (iPad)
That's sexy!
cool, but the fact that you can now do this with CSS is part of the reason that a new browser engine is so unlikely - one of 100000 things that css can do now and need to be supported :(
Maybe we should have kept CSS simple and JS optional. Maybe we took a few wrong turns...
This is brilliant!
this is super neat! love your site
This is pretty neat
I suppose the existence of bad uses does not invalidate the good but it feels like 99% of blurry image placeholder behavior is actually just preventing people from seeing anything unless they also run the ad and spying javascript that monetizes the site.
So a CSS-only way is neat and indisputably better but I think it's missing the point? The point of blurry placeholders isn't to make things easier or display better. The point is to make things worse. This write up is definitely making things better.
I know very little of css and to me it seems like a configuration file for rendering text, similar to changing default fonts ornsizes for matplotlib plots using plt.rcParams. How does this do inage blurring then?
..or use tailwind - https://tailwindcss.com/docs/filter-blur
Nice, but... it's not actually minimal. But nice.
Also a bit of nitpicking. While it provides a visual placeholder for an image that's being fetched, it does not reflect its content. So, when it's loaded we can see a completely different color palette and shapes.