The end of responsive images | Hacker News Reader

The end of responsive images

piccalil.li

70 pointsOuterVale20 comments

Summary: author is a fan of the new sizes="auto" and loading="lazy" browser features.

thanks, i couldn't bother reading the thing due to the ridiculous chest-thumping and self-aggrandizing.

There's two ways of setting a tone. One is to make the reader think/conclude a certain feeling. The second method is to tell them to feel the thing you want them to feel.

This article tells me to hype myself up, which had the exact opposite effect

He does ramble on and on about how awesome he is, and is enamored of the sound of his own voice.

I will say, it's now a little easier to understand why `srcset` and `sizes` are the way they are

A picture is worth a thousand words; this article about pictures contains no pictures and too many words. Probably AI slop

Not everything you disliked reading is just probably AI slop https://piccalil.li/about/:

> Workers first, AI technologies, dead last

> AI and LLMs are rooted in theft, exploitation, dishonesty and are over-promoted with ill-intentions for workers. Instead of running towards AI, we’re focusing on what’s actually important: content that helps people to succeed that is never produced by AI tools.

The style is definitely the over hyped and well expanded tone that AI is trained to mimic for sure though.

The author was waiting 14 years to excitedly share this?

IMHO, feels more like a polyfill than a final industry solution.

What, why? This is the web, so it has to be a solution that can handle old browser versions. Take away the old version and it's as small as it can be.

What a lovely story. Sad to see the others don't like it.

The most incredible thing is that a group of enthousiasts can join in the standards making process and actually move companies as big as Google and Apple. Even just a tiny bit.

Key passages:

>A few weeks ago, two patches landed in Gecko and WebKit… aligning [them] with Blink in supporting a relatively recent addition to the HTML specification: support for an auto value in sizes attributes.

>[T]he central issue with srcset/sizes was one of timing: a browser makes decisions about image requests long before it has any information about the page's layout… That assumption is… still the default behavior: if there’s an img in your markup, the request it triggers will be fired off long before any information about the layout can be known

>[T]hat is, unless that image uses the loading="lazy" attribute… [which] changes that entire equation — now those images are requested at the point of user interaction, long after the browser has all the information it needs about the sizes of the rendered image.

The mdn page is https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageEl... but what the mdn examples don't include is that the auto attribute can be used in addition to a specified sizes fallback. The Piccalilli article discusses this and includes example markup.

Correction: the mdn is https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... and in fact does include an example with fallback sizes. My apologies to the mdn authors – https://github.com/mdn/content/pull/43684

To the author: please consider putting a summary at top of the article.

> We’re not here to talk about picture.

Bro you just spewed 2 long paragraphs about picture at me. Don’t talk to me like that.

As someone who has seen srcset and picture but never used them in practice, the background was kind of useful. but I can understand people finding it annoying

I can't believe this doesn't mention Image Seam Carving. Surprise this was never built into browsers.

https://trekhleb.dev/js-image-carver/

I'd seen the technique, but never visualized like that. Very cool.

I think this is far too risky.

This doesn't help you if you want to save bandwidth, it worsens it.

It doesn't help you if you custom-crop images depending on the viewport size, because if you go that far to art direct, then you're not going to like the result of automated and unsupervised seam carving.

Just publish 3 sizes, maybe crop the smallest one if the focus area is too small. Done.

Building something like this into a browser would be a bad idea, as it's incredibly resource-intensive.

On the other hand you could just img { width: 100%; height: auto; } and still have more performance than websites that just send uncompressed PNGs in the hero.

Reply on news.ycombinator.com