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.…
Minimal CSS-only blurry image placeholders
21–30 of 78 posts
Re: Minimal CSS-only blurry image placeholders
#22This 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 y…
Re: Minimal CSS-only blurry image placeholders
#23Re: Minimal CSS-only blurry image placeholders
#24Why is the page so sluggish on mobile?
Re: Minimal CSS-only blurry image placeholders
#25Very 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.
In fact, LQIP looks better than most of the BlurHash examples in the gallery (https://leanrada.com/notes/css-only-lqip/gallery/); not sure if these were cherry picked or what.
Re: Minimal CSS-only blurry image placeholders
#26I'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).
Re: Minimal CSS-only blurry image placeholders
#27Very 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.
The half blue / half green image still looks better with LQIP than BlurHash. I was getting ready to use BlurHash in my app, might try this instead! In fact, LQIP looks better than most of the BlurHash examples in the gallery ( https://leanrada.com/notes/css-only-lqip/gallery/ ); not sure if these were cherry picked or what.
I did deliberately pick some "bad" examples like the blue+green image, and other multicolor images.
I wanted to add an upload function so people could test any image, then i realised I'd have to implement the compression/hashing in the client. Maybe i should!
Re: Minimal CSS-only blurry image placeholders
#28Re: Minimal CSS-only blurry image placeholders
#29Re: Minimal CSS-only blurry image placeholders
#30I 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 of blurry placeholders is to support loading a page with potentially hundreds of images (maybe with additional lazy loading, which doesn't need JavaScript these days) without blocking display of the page on loading those full images. I'm not sure why you think it has anything to do with forcing people to execute JavaScript?