Live data from Hacker News

Minimal CSS-only blurry image placeholders

leanrada.com

21–30 of 78 posts

Re: Minimal CSS-only blurry image placeholders

#21
post #9

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 placeholder is inline in the markup. It can be displayed before the image loads. Which is not inline. I have no idea what 99% thing you're talking about.

Re: Minimal CSS-only blurry image placeholders

#22
post #14

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 y…

see also the author's last note on the upcoming parsing feature of `attr()`, which would solve both problems (performance and verbosity) at once:

    

Re: Minimal CSS-only blurry image placeholders

#23
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!

Re: Minimal CSS-only blurry image placeholders

#25

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.

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.

Re: Minimal CSS-only blurry image placeholders

#26
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).

Re: Minimal CSS-only blurry image placeholders

#27

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.

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.

Author here: Definitely cherry picked ;)

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

#28
post #24

Why is the page so sluggish on mobile?

Probably because of all of the wildly complex CSS calculations it's running, as described by the article.

Yep, there are a lot of layers and compositing operations (maybe more than necessary?). I suppose it could be simplified further.

Re: Minimal CSS-only blurry image placeholders

#30
post #13
post #9

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 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?

Can't speak for everyone ofc, but not sure if I ever wanted blurry placeholders when images load fast enough, or found them anything but annoying when not. I think these bells and whistles only serve as designer's self-affirmation.
Post reply on HN