Hacker News Reader

Comment by buro9 | Hacker News Reader

If you are going to use this, keep in mind the advice given... set the height and width attributes of the image to prevent the page jumping around for lazily loaded images.

Which means, if you accept user generated content or images from any CMS or other source you really should be obtaining the image dimensions and using them in the HTML.

View on HN

This. It's bad enough already, pages can jump around many times if you start scrolling before they're "done" (which is hard to tell nowadays anyway). News site main pages tend to be the worst. Clicking through to a different article because the page re-rendered under my finger really gets my dander up.

I installed NoScript recently and was actually surprised by how many sites actually load low resolution placeholders and then swap them out with high res versions via Javascript. I'm assuming to avoid this jumping around.

That's probably an effort to load a faster, maybe a leaner version for mobile/whatever.

To actually prevent jumping (including on lean image load), I believe it would be more effective to simply set width and height.

I think it's a mix but most of the preloads I've encountered aren't just lower resolutions, rather they look like a smear of color. Like someone used a Gaussian blur filter with a 1000x pixel radius.

Yeah, I could understand a 128x128 pixel version or something but when it's 10x10 why are you even bothering.

Isn't that a thing of the past, with scroll anchoring being a feature of most major browsers?

Sadly, no. I experience many pages jumokng around wildly. Most often, the culprit seems to be ads that arrive late. Sometimes, it seems like pages are only requesting them when their intended position scrolls into view, so they pop up in the middle of the screen. So the browser must move either the upper half up or the lower half down to make space.

It's pretty depressing that so many otherwise modern UIs are totally broken whenever you're not using an ad-blocker

I always assumed this a was a dark pattern designed to get people to click on lucrative links swapped in at the last minute.

Brownian motion plus commercial (or other) pressure can produce things that look like dark patterns. Very similar to evolution in biology.

Assume that developers make essentially random mistakes or changes. Whenever anything happens that has a negative impact on metrics management cares about, there will be pressure to look what went wrong.

Any random change that has a benign impact on measured metrics, eg weird page loading that makes people accidentally click on more lucrative links, there will be no pressure to revert.

No one needs to consciously look for and implement dark patterns for this to work out.

It's very similar to how confirmation bias can make people question news they don't like until they find enough evidence to disregard them; but are just accepting news they do like.

How/Why would I do this with responsive/fluid layouts and dynamically changing image sizes?

How/Why would I do this with responsive/fluid layouts and dynamically changing image sizes?

You don't.

You're not required to use it on every image. It's a completely optional parameter that you add to individual images that might benefit from it.

You can use it on navigation icons that don't change size. Maybe in some of your boilerplate in the footer. Or in some sidebar content or a testimonial that you control. But if you have images of unknown size populating the middle of the page, don't use it on those.

But isn't that exactly the use case of lazy loading and also the source of all those problems?

The 1.2 kB icon in the footer is not really a problem, but the xxx kB article image some author uploaded with unknown sizes.

Those things will make my page jump around and will need to be lazy-loaded.

It should be possible in most backends to get size information from the image at the time of uploading. A pair of integers shouldn't be a lot of data to store as metadata for your HTML rendering process.

Use media conditions and source sets. https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

You would attempt to set some constraints on the image dimensions at the different breakpoints. For example, you can use percentages if you want a fluid amount. It's really to tell the browser how much space to allocate to the image before it's loaded. This is an old problem and pages that jump around would happen on slower connections.

Ok, my image has 100% width for screens up to 800 px width, what height value do I have to set? You simply don't know this information at the time when the DOM is built.

The idea to set fixed dimensions feels like it comes from a time where we did designs with tables and "optimized" sites for 1024 x 768 pixel screen size.

That was the time when you could tell that this image should be displayed 200 x 200 px in size and nothing else. And it fit. One way or another.

I would approach this thinking in terms of a known aspect ratio of the images and use a technique like this:

https://www.w3schools.com/howto/tryit.asp?filename=tryhow_cs...

Make no mistake, this is a silly problem to need to hack a solution for. So I would welcome lazy loaded images with space allocation before it's rendered with a responsive sizing.

Oh, constraints! These cute little math things that always work and are fundamental to the definition of layout geometry.

I doubt we’ll ever see them built into a browser, because all nice generalized things never get there.

Use the browser's onresize event to work out what changed and modify the width and height attributes accordingly. Alternatively, design with lazy loading in mind and use screen relative units (eg vw, vh, vmin and vmax).

Screen relative units are not possible to be used here - you have no idea how big the image will be on the screen, since you don't know how big the screen is.

Using js onresize event is a no-go, if JS is still needed the spec is worthless. Lazy loading images with JS worked before just fine, this has to be about not needing special JS for this feature.

No, parent is right: It's impossible to satisfy that recommendation, usually.

Screen relative units are not possible to be used here - you have no idea how big the image will be on the screen, since you don't know how big the screen is.

Screen relative units represent a percentage of the screen size (technically speaking it's the viewport really). You don't need to know how big the screen is; you're tell the browser to use, for example, 25% of the viewport height when you set something to be 25vh. If you want 4 images vertically that's really useful. That way the browser knows it needs to put a box 25% of the screen height in the DOM where the image will be loaded later so there's no layout thrashing.

Using js onresize event is a no-go, if JS is still needed the spec is worthless.

The parent suggested they would want to change the width and height attributes of the image when the user resizes their browser. That's exactly what the resize event is for. If you want to display a fixed size image you can use fixed width and height attributes. If you want the image to scale with the viewport size you can either use units that represent a relative size or you need to use JS to modify the attributes. Heck, you can even use media queries to mix and match and have fixed size in some devices and relative in others.

Lazy loading images with JS worked before just fine..

Except you needed JS to do it. With the new HTML spec you get the benefits of basic lazy loading without needing the additional weight of some JS code. That's good.

But you never know that an image should cover 25vh! That depends on the size of the viewport in total, the resolution and the specifics of the layout situation, things like text size. And almost always the width of the viewport decides image width and thus the height of the image.

And that's before resizing anything.

This totally misses the point. I can't run all those calculations while rendering a website. The browser needs to be intelligent enough to not dynamically jump around in the viewport when an element finished loading. Just fix the viewport and attach at the top and bottom.

And relative units don't fix this either as that information still misses the ratio of my image. If it's 100 vw, how high is it? I don't know this information without fetching the image, doing calculations and dynamically updating the DOM with that information.

That sounds like a problem that should be fixed in CSS. Ideally, it should be possible to specify that an image should have a width and/or max-width of 100vw, 100% of its parent, or whatever, taking box-sizing and paddings into account... and then specify that its height should be a certain percentage of its own width. The server already knows the aspect ratio, so it can deliver this information in a 'style' attribute.

I haven't been following the latest developments in CSS for a while, so maybe it's already possible to do this?

I do this in production a few places by setting a div with no content or only absolutely position content to have padding-bottom of the aspect ratio in %. That gets calculated from the width, so if the image is 4:3 my ratio is 75%; 200px wide becomes 150px tall as well. Then, I set the image as a background to the div or absolutely position it inside to fill the space, and it's responsive to the layout while also reserving space for itself.

This reminds me of all the icky hacks "everyone" had to do going back years. (remember the star hack?)

I am not going to do this. This is such a pervasive issue, and with an _endless_ difference in screen sizes and millions of pages of content... not going to happen.

This kind of problem is exactly what the browser is best at solving. A problem everyone has on most pages on the internet.

Refusing to specify your image sizes denies the browser the information it needs to solve this problem.

Maybe, but I think this is a solvable problem from the browsers perspective. In my experience building websites the need for image dimensions is near zero.

1. The penalty for not displaying image dimensions is nearly insignificant because almost _all_ images that you would put width/height on are from content managers, not designers.

2. Mobile content: On a phone the content moves down after the image is loaded. (everything is just a single column) Which is a preferable action than a big empty space. So, I prefer _not_ including dimensions on user content for phones.

3. Responsive design: All CSS I have been using for years now has "max-width:100%".

Therefore (since a lot of traffic is mobile) most (rough guess) of images loaded from sites I've worked on the image dimensions are recalculated as soon as the image is loaded anyway.

4. Srcset: Multiple possible images downloaded that are _chosen_ by the browser at run time. You already have to provide dimensions. But what if they aren't exact? Go back to #1.

5. Web design: I can't even recall the last time I put an image in a design using the <img> tag that affected layout. (maybe if you go back to the 90s this would have mattered)

Instead of specifying how big your images are in html (or css), you are proposing the browser should magically guess how big your images are going to end up? Or should it not render anything until all your needless images are downloaded?

Is there an actual problem in identifying what images correspond to your markup and adding an appropriate attribute? (asking, not a web dev)

AFAICT the problem is solved, this is the necessary protocol - not even a bad one, use it and it will work.

If you can give the browser the image size with JS, then the browser can figure it out on it's own.

Rarely do we specify the width of many, many objects and they display just fine. (consider tables)

By adding an attribute I meant server side, not client-side if that's what you mean.

If you defer (down)loading of images, and layout depends on unavailable size/aspect-ratio of an image, you get layout updates - same would happen if you lazy-loaded contents of tables.

What is the problem you would like solved and what do you propose for the browsers to do? Ancestor post was about avoiding layout changes as new layout-critical information arrives. Judging by your sibling comment, you seem to prefer layout updates with content popping up.

Using the width/height value on an <img> tag feels simply archaic and more importantly doesn't add value to the site visitor.

Why?

1. srcset [0]: the browser chooses the size of the image, not the server.

2. CSS/Responsive images [1] : Almost all (I am close to saying 100%) of images I have loaded on websites have their width/height adjusted by CSS.

Layout updates are often unavoidable in most circumstances surrounding images, there is just no getting around it.

So instead of pining over the past, we should adapt for the future.

I feel like this argument is the same I had with print designers in the late 90s who made every page a full image because they couldn't handle not having full control over the layout.

[0] https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageEl...

[0b] https://cloudfour.com/thinks/responsive-images-101-part-8-cs...

[1] https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

Do you mean like when you click on a search result in Google Chrome on Android, then go back want to click the next one but in the meantime an animation starts showing alternative search terms so the click goes there instead? And you don't even need images for it

Reply on news.ycombinator.com