The Humble img Element and Core Web Vitals

What you describe is already possible with the `srcset` attribute: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

What's the use case though?

@container queries have been discussed/proposed before, but I've never really experienced a time where I wished they were a thing.

For different screen resolutions and orientations, you have media queries, and I find if you build for mobile first and expand the UI for tablet and desktop with min-width media queries, it's generally pretty straightforward. It may seem like an ugly hack but generally speaking the main question is what device is being used. Most users don't resize their windows on desktop all that much like we do.

With image sizing for containers that may change size, you can abuse background-image and background-size: cover for a quick solution, and for a long term solution you can use an image element and a parent element.

  .img-responsive-cell {
    /*
      this is a div or something
      parent element to the img.
      you would size this 
      according to a grid 
      system containing 
      element for width and 
      you could sort the 
      height out with 
      %padding or something 
      else depending on what 
      you're making
    */
    position: relative;
    overflow: hidden; 
    /* 
      overflow hidden will 
      make sense in a moment 
    */
  }

  .img-responsive {
    /*
      the img element
    */
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
    min-width: 100%;
    min-height: 100%;
    width: auto;
    height: auto;

    \*
      or more recently you 
      can do ->

      width: 100%;
      height: 100%;
      object-fit: cover;
    *\
  }

This lets the image grow to fill the containing element, maintain aspect ratio so it will essentially be zoomed, centered with left/top and transform, and this also makes for easy hover effects, like so:

  .img-responsive:hover {
    transform: translate(-50%,-50%) scale(1.2);
  }

Now yes, this isn't attractive and it doesn't give you fine control over what image you're loading, but CSS is ugly anyway and it's a way to achieve a one-size-fits-all solution for the sake of getting something working responsively early in the lifespan. Optimise the hell out of the images and it'll be ok for a minimum viable product.

----

I think the problem with container queries as a concept is that JavaScript is a naturally better tool for the job when it comes to loading media dynamically -- after all you probably want to lazy load images anyway, especially below the fold or if you have a lot of dynamic views.

As someone who has tried to browse the internet on public transport in the UK, I'm a big advocate of lazy loading.

If your website lazy loads images, it's pretty simple to build in a little extra logic to load particular images for particular container element size-ranges.

----

Also, bit off topic but related: in the absence of container queries, we use media queries and srcset, but maybe background-image + media queries might seem like a good plan?

However if I recall correctly as soon as the stylesheet is loaded it downloads all the images referenced in it, so it doesn't achieve much except to reduce strain on painting I guess.

That's why I just keep things simple to begin with.

Ugh yes. The element containing the image is literally the only thing that matters, tying the image to the screen size is pointless and often infuriating.

For those who don’t see this, imagine this scenario- You have a fluid 3 column layout. The layout has multiple break points. Inside one of those columns you have a grid of images which itself is fluid and has breakpoints, these breakpoints differ from the layout breakpoints. Now what should the srcset be on the individual images in the grid at a 1000px screen size? The answer is why the hell am I being forced to figure this out? The browser knows how wide the container will be around the individuals images, help us out here and use this value to determine what image should be selected in the srcset.

In theory this matters, because we could load the perfect image size for our element, if only HTML could.

But in practice:

1. You wouldn't want to have thousands of slightly different size variations of the same image generated and cached on your CDN/server.

2. You would quantize and keep a few sizes (like small, medium, large, xlarge).

3. Once you do this, screen size becomes good enough of a heuristic to figure out which of the above set of quantized images you need for an element.

4. Ergo, all is as it should be.

There is a proposed feature in CSS called "container queries" that does exactly this - media queries on the parent container of an element. There are performance concerns and syntax concerns, but they probably will appear in stable versions of browsers in the nearish future.

In the meantime you can enable a version of them in Chrome using a Chrome flag.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Contain...

You can make sure it's not abused at all if you sign the URL. In terms of performance it's a free feature because once the image is generated, you no longer have to check the signature (you only check it first time to generate).

I'm fairly sure this is not true. I've seen webpages take >1 sec to load because of a single unoptimized image that weighs around 300mb or more. Yeah, idk how they get that big either

That sentence is phrased a bit odd, but if you're trying to say media size is even same order of magnitude as JS/CSS size in practice, then... no. Not even close.

Google webmaster tools has a basic chart that shows web vitals, likely as seen from google bots.

You can setup your own lighthouse setup, and measure the production sites from any number of vantage points, ideally from where you have most users coming from.

https://treo.sh/ perhaps ?