4 ms·

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

martin-adams 7y ago
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.
- wruza 7y ago
  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.
- martin_a 7y ago
  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.
  - martin-adams 7y ago
    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_css_aspect_ratio_43 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.
onion2k 7y ago
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).
- onli 7y ago
  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.
  - onion2k 7y ago
    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.
    - 7y ago
reaperducer 7y ago
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.
- martin_a 7y ago
  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.
  - WorldMaker 7y ago
    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.
throwanem 7y ago
Use media conditions and source sets. https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images 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.

wruza 7y ago
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.
martin_a 7y ago
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.
- martin-adams 7y ago
  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_css_aspect_ratio_43 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.

onion2k 7y ago

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

onli 7y ago
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.
- onion2k 7y ago
  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.
  - 7y ago

reaperducer 7y ago

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.

martin_a 7y ago
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.
- WorldMaker 7y ago
  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.

throwanem 7y ago

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