Live data from Hacker News

Minimal CSS-only blurry image placeholders

leanrada.com

51–60 of 78 posts

Re: Minimal CSS-only blurry image placeholders

#51
post #46
post #44

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.

What do you mean? In my opinion this library does a very good job of representing the image’s color palette considering it’s encoded into a single integer. (Even smaller than usual because of CSS limitations, only 20 bits!) You don’t even need JavaScript to decode that integer into the image. The underlying CSS may be complex, but for the user of the library it definitely feels minimal in a good way.

In the gallery https://leanrada.com/notes/css-only-lqip/gallery/ there's a good example of what I mean - the bottom right image or 4th from the end. A completely different image in comparison to the gradient.

As for the minimalism, I understand what you mean. But I understood the "minimal" part in regard to implementation, not usage. If we only mean usage, we can say the same about a lot of libs, that they are minimal. Yeah, it's minimal for the end user, but under the hood it is not as minimal. It's not anything bad, it's just how I interpreted the title.

Re: Minimal CSS-only blurry image placeholders

#52

Earlier quoted context omitted.

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!

I could tell and I really appreciate it. It's really helpful to see both the good and the bad.

Great work!

Re: Minimal CSS-only blurry image placeholders

#53
post #44

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.

I see two issues, let's say "opportunities":

First is the limitation to one hue value. Something like the Sunflower (blue + yellow) is just yellow. Maybe there's a tradeoff that could pack more hue but with less luminescence.

The second is how the primary color is selected. Several images (plant on grey background, street food vendor) appear to be averaging across the image and getting a grey value. By selecting better for the predominant color and its placement, the greys would appear on their own.

Re: Minimal CSS-only blurry image placeholders

#54

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

It's all additive so each new feature does indeed add complexity, but my impression is that it's often the older features and all their quirks which are the most difficult to implement. Adding a few math functions is much easier than ensuring compatibility with CSS2 floats.

Re: Minimal CSS-only blurry image placeholders

#55

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…

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

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

Re: Minimal CSS-only blurry image placeholders

#56
post #13

Earlier quoted context omitted.

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?

Indeed. So the visitor need only wait for the 20mb javascript bundle, but not the 600kb of images, before he can see the 1kb of text that he visited the site to read.

Sounds like you're in favor of a version of blurry placeholders that's implemented in less than 1KB of CSS.

Re: Minimal CSS-only blurry image placeholders

#57
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.

Re: Minimal CSS-only blurry image placeholders

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

Re: Minimal CSS-only blurry image placeholders

#59

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…

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

Re: Minimal CSS-only blurry image placeholders

#60
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.

Look at literally any "newspaper" website. From the smallest local paper to the NYT.
Post reply on HN