[css-conditional] [css-contain] srcset and sizes interaction with container queries

[una]

With container queries, the way developers write responsive styles changes from querying the global page for information to querying for a parent with containment for information. This shifts responsive paradigms. One case I can forsee is the need to query the parent for sizing and placement of its children. This includes srcset and sizes for responsive images

See also, the need for cw and ch units: #5888

Would the following be able to work with container queries instead of global queries? (ignore syntax, just trying to show the idea):

<img srcset="elva-fairy-480w.jpg 480w,
             elva-fairy-800w.jpg 800w"
     sizes="container(max-width: 600px) 480px,
            800px"
     src="elva-fairy-800w.jpg"
     alt="Elva dressed as a fairy">

<picture>
  <source container="(max-width: 799px)" srcset="elva-480w-close-portrait.jpg">
  <source container="(min-width: 800px)" srcset="elva-800w.jpg">
  <img src="elva-800w.jpg" alt="Chris standing up holding his daughter Elva">
</picture>

[chrishtr]

@yoavweiss @cramforce WDYT?

[chrishtr]

@mirisuzanne

[cramforce]

@chrishtr The use case I was mentioning earlier basically the opposite. Containers often determine the width of their child. So what I want is:

<main sizes="50vw">
  <img srcset="1.avif 1920w, 2.avif 640w"><!-- no redundant sizes attribute on children of main -->
  <img srcset="1.avif 1920w, 2.avif 640w">
  <img srcset="1.avif 1920w, 2.avif 640w">
</main>

[mirisuzanne]

I completely agree that this would be a very powerful and useful feature. My understanding was that responsive image sources are resolved before styles – making this reference impossible. But I'm not a browser engineer, and would love to discover that I'm wrong about this. :)

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional] [css-contain] `srcset` and `sizes` interaction with container queries.

The full IRC log of that discussion

<astearns> topic: [css-conditional] [css-contain] `srcset` and `sizes` interaction with container queries
<astearns> github: https://github.com//issues/5889
<dlibby> una: next issue is related - how to deal with responsive images in container queries
<dlibby> una: would like to explore the solution space, since it seems like it'll be pretty common
<dlibby> una: adding a ??? to srcset, setting images on each compute, since they come from server
<bkardell_> q+
<dlibby> una: how should container queries interact, and background images are also a consideration
<bkardell_> how would this work with preloading? https://web.dev/preload-responsive-images/
<dlibby> s/???/new syntax/
<dlibby> una: do something simliar to media queries but seems important to consider for container queries
<astearns> ack bkardell_
<dlibby> bkardell: preloading - see linked article. you can't know what to load until later
<dlibby> una: yes, tricky because working at compute time, not sure how this works for viewport size
<dlibby> emilio: you can estimate what your viewport is
<dlibby> emilio: you can make a decent guess in iframes
<dlibby> emilio: you can't really do this in containers
<dlibby> iank: relatively sure that gecko and chromium reference image via background: url(foo), but can have multiple decls
<dlibby> iank: UA load images after computed value time so you don't load lots of things in the background
<dlibby> iank: it's a performance tradeoff
<dlibby> emilio: <img> tags are a little more important as user wants to immediatly see it
<dlibby> florian: worried that this could make slow connections slower
<dlibby> florian: you normally don't get all resources at the first request, progressive modification, which happens more on slow networks. as this happens container can change, possible to congest/thrash network
<dlibby> florian: that sounds unfortunate side effect
<dlibby> una: if youre using container queries and there's a hero, or in a card, or sidebar, those are different
<dlibby> una: if container queries allow for composable styles in components, I can't imagine that we can't have different image sizes based on the size
<bkardell_> not just image sizes maybe different art direction too?
<dlibby> una: not sure if it is slower to load a bunch of images first, or layout first then download other images
<bkardell_> I suggest we send this to RICG :)
<dlibby> florian: use case makes sense - should and can are different questions
<dlibby> florian: if you have multiple small parts, many changes could be happening, and as the stylesheet comes in over network, you might end up loading all the images
<dlibby> florian: ending up there sounds bad, but perhaps there's another approach
<dlibby> myles: problem appears endemic to container queries
<dlibby> florian: most thrashing doesn't hit the network for each change
<dlibby> una: perhaps we can scope to initial load to avoid this problem - maybe solves the majority use cases
<dlibby> emilio: not sure - if you resize the window, you'd bet stuck in possible suboptimal state
<fantasai> I was about to say the same thing also
<dlibby> myles: I don't think visual layout should be permanently affected based on network speed
<dlibby> myles: CSS shouldn't be sensitive to timing of bytes on the wire
<dlibby> una: might be misunderstanding. when we figure out the layout size keep that image
<dlibby> una: refresh page would get different images
<dlibby> emilio: layout while stylesheets are outstanding is common. stylesheet in body can affect the page layout, this should be taken into account
<dlibby> iank: the place where this functionality may make sense is html layout. some components are already stateful, but this should be carefully considered
<dlibby> e.g. a oneshot load - how does this affect the html layout, something to consider
<nicole> a balance btw not requesting unnecessary images and not waiting to load images until css is done parsing
<dlibby> myles: maybe specify behavior, UAs can use different heuristics
<dlibby> myles: CSSWG doesn't have to specify when loads are triggered
<dlibby> iank: option for this would be adding to Image specificiation (perhaps additional data on <img>) once this has been laid out and it reaches 'stable' state, then UA can fire off request
<dlibby> ???: problem with containment in general?
<fantasai> s/????/nicole/
<fantasai> s/???/nicole/
<dlibby> emilio: perhaps one approach is to define what the behavior should be (lazy or something). just a gneeral problem with containment.
<dlibby> s/containment/container queries/
<dlibby> iank: reasonably easy to polyfill, prototype, iterate to discover 'good behavior'
<dlibby> iank: don't have to nail down spec text right now, we can try to find optimal via prototyping
<dlibby> bkardell: might be good to ask folks on ??? CG
<jensimmo_> yes, do ask Mat.
<dlibby> bkardell: to the point of wanting different size, you might want different art directives(?)
<dlibby> astearns: is it possible to load different images?
<dlibby> iank: yes this is possible to get different urls
<dlibby> astearns: that is for separate declarations, but this is for a single declaration
<dlibby> iank: i was referring to img tag attribute, there's nothing in CSS currently that allows for this
<dlibby> nicole: having it in CSS should be the same problem as having this specified in the html itself. likely has same characteristics
<dlibby> una: i recognize that this is probably for specification in HTML
<dlibby> una: glad bkardell brought up different images - third party service could provide different crops
<dlibby> bkardell: precisely, that's what I wanted to be recognized
<dlibby> astearns: what else would you like to get from the group?
<dlibby> una: this conversation basically
<dlibby> astearns: perhaps prototyping per iank is the way forward, thanks for bringing it up

[scottjehl]

Can't speak to the implementation side, but I like this idea, @una. Just like with container queries, I think the container size is what we typically want to know for specifying image sources. Also, in the off chance that media comes back to video, it'd be nice to see this working there as well.

[eeeps]

This seems really exciting for art direction (e.g., <picture><source container> or whatever).

However, part of the goal of <source media> and srcset + sizes is to allow UAs to load images immediately, using information contained within markup alone, and I don't see how you resolve a cw or a container() or whatever, without waiting for style and layout.

For art direction... maybe that's a high performance price we have to pay to enable art direction within responsive components, which seems important.

But for sizes and srcset selection, once you've waited for layout, you don't need sizes at all. (See also: whatwg/html#4654)

I can maybe see a path forward to instant loading here if the queried container, itself, has a sizes attribute, which can be resolved using just viewport size... e.g.

<div
  class="container"
  sizes="(min-width: 800px) 800px, 100vw" />
  <img
    srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1200w"
    sizes="container(min-width: 600px) 33cw, 100cw"
  />
  [more images with the same sizes go here]
</div>

But reading, writing, and maintaining sizes is already extremely difficult; this figures to make it worse. And it doesn't play nicely with container query use cases where the author doesn't know the container size (e.g. user-resizable components)

[chrishtr]

I don't see how you resolve a cw or a container() or whatever, without waiting for style and layout.

Under this proposal, the selection of the size would indeed depend on style and layout. Which would mean the loading of these images would be significantly delayed. The same problem occurs with loading=lazy, because the only way to determine if the image intersects the viewport is to do layout.

However, there are real advantages to this pattern, and there may be many good use cases where the image is not critical for first-load rendering time.

[joemcgill]

The natural conflict between prioritizing the ability to preload images before scripts/styles load and the desire to optimize the image loaded based on layout was always the trickiest thing to solve for responsive images. What I see above are basically two different use cases, each of which (as far as I can tell) would need to carry different assumptions about how that prioritization works.

1. Preload images based on a container width

To make this work, you would need to let the browser know what the container width is intended to be before layout is calculated, by applying something like sizes attribute to the container. Any children declaring a srcset with w descriptors that don't supply a sizes attribute would default to the closest ancestor's sizes rather than the current default of 100vw. This would satisfy the use case @cramforce mentioned above.

If the image does include a sizes attribute, it could use a container query to declare relative layout intent based on the closest ancestor's sizes attribute as @eepps example shows. There's some developer overhead that seems redundant with this syntax, but I think the possibilities would be pretty powerful.

2. Lazy load images based on container width

In the event that image markup relies on a container query or container relative measurements in it's sizes attribute, and there is no ancestor supplying a sizes context, then image loading would either need to be deferred until after layout is calculated (i.e., treated similarly to lazy loading) or, in cases where loading="eager" is intended, the file would be requested using the 100vw as the default sizes context when calculating container-relative sizes for image srcset parsing. This isn't ideal, but no different that then current assumption for images supplying a srcset without a sizes attribute.

I think those are acceptable constraints/tradeoffs for the benefits that come from being able to use these new tools in building reusable interface elements that respond to their layout context.

[Wilto]

srcset and sizes interaction with container queries

One loves to see it.

I think @joemcgill nailed my thoughts on this, but one thing worries me a little: “lazy load images based on container width” feels like both a sensible default for omitted sizes and a powerful feature in the right hands—like, “I want lazyload on this img in this CQ, so I’ll skip writing sizes” sounds great on a couple of levels.

What worries me is that sizes attributes (and please know I mean this with all love for the feature) are a huge pain to write by hand. Understanding the difference between preparse and layout calculation timings is a lot to ask of a junior developer that just wants to put an image on a page, and asking devs to calculate an accurate sizes attribute in order to shave off imperceptible-in-the-moment differences in load time could be a tough sell. “You can go to all the trouble of writing a sizes attribute and the image shows up quick and looks fine, or you can not write sizes and the image still shows up quick and looks fine,” y’know?

I’m a little concerned that the lazyloading pattern would end up telephone-gamed into “we don’t need sizes in CQ,” and we’d be effectively giving up preload on srcset-powered images inside CQ. That said, srcset has always felt a little like a stopgap. So, hm.

[MattWilcox]

That said, srcset has always felt a little like a stopgap

I've thought the same about sizes tbh. When we have aspect-ratio on hand and available, plus loading=lazy, then we can safely let the browser decide which asset to pull because it already knows the width it actually needs all by itself without hinting.

[yoavweiss]

belatedly catching up...

I agree with @eeeps about the inherent tradeoff here, about the ability to go with nested sizes and about the inability of humans to make sense of that.

I similarly agree with @chrishtr that for anything outside any initial viewport, lazy loading it has no performance cost and should be encouraged.

But, that leaves us with "images inside a container query that are in an initial viewport of some form factors".
What would be our developer advice in that case?

• The initial layout is fast if the relevant CSS is fast to arrive. Can we simply advise developers to make sure the layout structure of their initial viewport is laid out by inline styles? Is that a reasonable thing to ask?
• While humans won't be able to generate nested sizes attributes, tools might. <insert "the tools will save us" meme here> Is that a reasonable path?
• We tell developers to avoid Container Queries in the initial viewport? (even if we would, they are not likely to listen)
• We live with slower LCPs for developer convenience? (Not a fan of this option, but might be interesting to quantify the damage IRL)
• A better option that has alluded us for the last 6 years?

I'm not sure what the answer is, but seems like we need one.

[rik]

The initial layout is fast if the relevant CSS is fast to arrive. Can we simply advise developers to make sure the layout structure of their initial viewport is laid out by inline styles? Is that a reasonable thing to ask?

I don't think it's reasonable. Maintaining an accurate set of inline styles for the initial viewport is a very hard task and I've never met a team who does it well. (Sidenote: it is very annoying to see this recommandation in performance tooling as it is quite unrealistic)

---

Currently, responsive images can be fetched before the external CSS has been parsed. Changing this behaviour because of the introduction of container queries seems like a breaking change to me. I think browsers could keep the existing behaviour if no condition in sizes targets a container. Using the draft syntax:

<!-- Starts fetching with only HTML known -->
<img srcset="elva-fairy-480w.jpg 480w,
             elva-fairy-800w.jpg 800w"
     sizes="(max-width: 600px) 480px,
            800px"
     src="elva-fairy-800w.jpg"
     alt="Elva dressed as a fairy">

<!-- Waits for external CSS to choose an image to fetch -->
<img srcset="elva-fairy-480w.jpg 480w,
             elva-fairy-800w.jpg 800w"
     sizes="container(max-width: 600px) 480px,
            800px"
     src="elva-fairy-800w.jpg"
     alt="Elva dressed as a fairy">

[chrishtr]

• The initial layout is fast if the relevant CSS is fast to arrive.

I think this is reasonable to aim for a first layout that runs fast enough. Recent features such as content-visibility: auto make it feasible to make large documents have fast first layout.

This leaves the question of whether it is reasonable to expect the relevant CSS to be fast to arrive. This would require critical styles to be inlined into the HTML, or something like Early Hints, if "fast to arrive" means no extra round-trips.

[bkardell]

A few of us are planning a breakout to discuss this topic/use cases on Thursday March 11 at 9am ET, the invitation for anyone intersted in joining that is open.. Please reach out to @una or myself and we'll share a meeting link/calendar invite.

[una]

Informal breakout meeting notes: https://docs.google.com/document/d/1AgCqgnPymQPzwdl0-BgNd22Sc01xXebjVezkme2ofu4/edit?usp=sharing

Responsive Images in Container Queries
Attendees: Brain Kardell, Simon Pieters, Yoav Weiss, Una Kravets
Issue: https://github.com/w3c/csswg-drafts/issues/5889

Concerns:
Yoav: The only path I see to solve this problem is to add some kind of nested sizes attribute… Like, a sizes attribute for the container, but where the size is about _that_.  As far as we can tell from content in the wild, people are getting the existing stuff wrong.  Maybe if we take that job away from people and gave it to robots...or really good tooling.  We have a similar problem is lazy loading where … well, it feels like a related problem, people want to talk about "the initial viewport" - but there isn't a single one, there are many.
Simon: Layout needs to be known for the CQ, which would delay the loading of images
If you know containers size, couldn’t that be calculated based on the viewport?
Maybe – considering stable container size per viewport size mapping (Yoav)
Una: With responsive images now, the image changes as the page resize in img attribute, thats what would happen with CW
Media attribute this would be a must 
Picture attribute doesn’t do this bc theres no defined callback for when attributes change, and you might not always want to load a new image when the viewport changes (you wouldn’t want this to happen for background tabs) (Simon)
Yoav: There is a right answer, its just not a markup-based answer
Server-side logic that calc all the viewports possible, which images are in the initial viewport for the layout, and then gives you the right answer at server time
Impossible to bake this logic into HTML
Can do some sizes syntax in HTML
Need layout to happen in order for lazyloading and CQ
Brian: Consider users on low-bandwidth metered connections
There are good answers, but there might not be a “right” answer
Should you load a new image as things scale? Maybe
Una: People don’t resize screens *that* often to the point that not sending a new image after initial load would necessarily degrade experience
Yoav: This isn’t the main problem, the issue is that these images will be by definition slow
Cause adoption issues for container queries, or make the web slower
Brian: Users open drawers on websites, elements that slide into the layout would be the same problem
Simon: New images loaded in background (hotswapped)
Tricky problem here is figuring out what to do with images in CQ
Do we accept these images to load slowly? Nested sizes syntax with container?
Una: [proposed a container attribute in sizes](https://github.com/w3c/csswg-drafts/issues/5889): `sizes="container(max-width: 600px) 480px, 800px"` in the issue
Simon: requires layout to evaluate this CQ
Yoav: Another idea: an attribute on the container thats relative to viewport
Simon: Can then evaluate CQ before layout is known
Yoav: [[proposed example in jsbin of sizes=(max-width: 900px)... with an image inside of it that has container=”some syntax”]](https://jsbin.com/xiyofeyuji/edit?html,output)
Would be for both viewport and container queries
People get srcset wrong all the time, we need to give people reasonable tools to generate that
Brian: What if element is a grid cell
No 1:1 mapping from grid to container size
This issue exists today with responsive images
Grid cell doesn’t have a 1:1 mapping to an element, the size can vary
Brian: think of it in a table – the app provides the TR, and you give it TD’s, they wind  up displayed in rows. The available width for whole row but what youre trying to design is a card
Size of cell depends on how many cells there are
Yoav: we need build tools to figure out the perfect sizes value for you, then bake that information back into the HTML
We need a tool to use this, or users won’t be able to get the size right manually
Simon: If you has such a tool, why not just calculate the image size attributes directly
Brian: can we reason through one of the use cases and see if Yoav’s example even makes sense? One of the features of CQ is that you can reason about a thing without knowing where it will live in the page (without that page)
Who would use this tool and how?
Can do responsive design today if you start with viewport, why recreate that vs focus on container queries
Simon: it still lets you use container queries and not think about the viewport while designing. The consumer of the component may have to use sizes attribute on the container so the browser can load the appropriate image before it knows the layout
Goal: load CSS and image in parallel
Yoav: we tell people they need to run this markup through optimization tool that takes the viewport into account (initial size of container relative to viewport) – not a task for humans, essentially recognizing current status quo (i.e. sizes isnt usually very accurate)
Suggesting: we will have some indicator on the image that its a child of a CQ, or on the container that its a container, and exclude images within it from preload scanning unless theres an exclusive sizes attribute. And have sizes attributes that are generated somehow
Simon: Is it better, if you have to wait until layout to load the wrong image or to just wait.
Yoav: It is a gamble.
Brian: I think like I said there are good answers, not perfect ones
Una: I don't think people expect it to be perfect, I think that mostly people want to avoid worst cases - sending a giant image to a tiny device or something.  
Yoav: It might be interesting to do a study - there have been some… cloundinary did one to gather up stats about what happens in the wild today vs final layout dimensions.  It could be a good way to get insight into how well we're even doing today.  The use cases for the picture media query on the container queries - you need to be right.  With srcset, the worst case scenario is you might get the wrong one (first?). 
Una: Another example use case to consider: Sometimes you want a different aspect ratio or even differnt media for different screen sizes - you want different art direction
Yoav: That would require a perfect sizes attribute or some tooling or people will get this wrong.  I think in a way what we were suggesting was that maybe container queries could be built or compiled and I'm not really sure that is what anyone wants.
Una: I wonder if there is a world in which you can use responsive images in container queries in which this will happen after layout.  They can use placeholders for those images, for example… I don't know if that is the worst thing.
Yoav: It will be slow.  But we see now with lazy loading people are sprinkling it everywhere that people are making their pages effectively and measuably slower.  Essentially, if you make people between what is easy and what is good for users - they will go with easy every single time. We can do some education, but ultimately I think this will not help us.  I think we need to figure out a way in which we can give people actionable advice that is not super hard that gets them the right thing.
CSS images in general are loaded late
If we say that we need the layout before downloading the image, we have a similar situation w/what we have for background images today
Can preload critical bg images, or the best practice is to make them decorative
Una: Shopping example (products in a grid) grid → hero → cart component style
Without responsive images, really degrades experience/usefulness of container queries
AI: 
Schedule another 30 mins in a week to continue discussion

[astearns]

@una can you export the google doc into an archival format and send it as an attachment to www-archive? Then we can have a more permanent link to add here.

[jakearchibald]

I have a hunch that many (most?) sizes in the wild are wrong, and users are getting oversized images as a result. Eg, a lot of the sizes in https://news.sky.com/uk are just 100vw.

Auto sizes might be a net win for performance, even if it delays image loading until after layout.

Call it sizes="delayed-auto" or whatever if you want devs to think twice about using it. But for stuff below the fold (which may already be using loading="lazy", it doesn't seem like a big deal.

[MattWilcox]

Fwiw I don't think the use case of "request an asset as fast as possible" is anything like as important as "load the right asset and avoid wasting potentially hundreds of Kb of inappropriate image data".

The part of the feature that allows for early http requests is far less impactful for any page of a realistic size than getting the more appropriate asset for the context in use. Given that the majority of the time "saved" by this behaviour is actually dns lookup time and/or connection establishment... those are mostly redundant? A huge portion of images are going to be on the same domain or a CDN that don't incur an extra lookup, or over http2/3 which don't suffer the same connection overhead.

Unless I'm missing something? I'd happily ditch the "load a thing as soon as possible" for a "load the right thing".

[jakearchibald]

Given that the majority of the time "saved" by this behaviour is actually dns lookup time and/or connection establishment...

Ohh, on that note, if all the potential sources for an <img> are the same origin, but not the same origin as the page, the browser can start that connection before layout.

I think this might be a common case. Eg images on https://www.theguardian.com/uk are on a different origin to the page, but the images themselves are all on the same origin as each other.

[jakearchibald]

Ugh, unless the image turns out to be display:none or within display:none

[MattWilcox]

Ugh, unless the image turns out to be display:none or within display:none

True, though I'd think that's not any different than how that scenario would be today anyway?

Also; don't we already provide a mechanism for doing quick DNS lookups when you know a domain will be needed later in the page? https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch

I'd say that it's easier to know that ahead of time as a page author or content editor, than it is to know what sizes an asset will render at once loaded - in order to provide a sizes property value that's actually correct. Or to be more plain: it's simpler, more reliable, and easier to automate what domains the assets of a page use and bang a dns-prefetch in the head for those, than it is to generate real values for the sizes property at different breakpoints.

[eeeps]

I'd happily ditch the "load a thing as soon as possible" for a "load the right thing".

One of the core design constraints for srcset (almost a decade ago!?) was that it not add any delay to load start. The strongest argument for that IMO was "a performance feature shouldn't slow down your image loads".

Tying layout-aware responsive image loading to lazy-loading makes sense, as we're not adding any additional delay. Tying it to container queries makes less sense, from this point of view. But it would be nice to quantify both:

1. The cost of the author-facing complexity required to allow pre-layout load starts (here I'm mostly talking about sizes); how many authors are doing responsive image markup badly and what impact is that having on users?
2. The potential user-facing performance costs of waiting for layout to select responsive image resources.

I'm doing some analysis on ① as part of the HTTP Almanac this year, and am very excited about it. I have some A/B demos that investigate ② synthetically, but don't have good ideas about how to extend that analysis to the web, as it exists, as a whole.

[zcorpan]

Also see: whatwg/html#8007

[grigs]

I’m a bit late to this discussion, and I’m not certain how much of a contribution this will be to finding a solution, but I wrote an article about the challenge and my feeling that maybe this is the time when we should revisit some of the assumptions that led us to the responsive images syntax.

[rjgotten]

Has any of the discussion for this considered looking at the problem from a different angle?

srcset had one major design flaw, or rather, two related ones:

1. no constraint on the images in the set being required to be same-aspect; and
2. no a-priori knowledge of the aspect ratio.

Introduce that constraint and introduce an attribute that can provide that aspect ratio and suddenly for initial viewport rendering you can speculatively download whatever is smallest. If once layout happens the image hasn't been downloaded yet, then you can abort the pending request and transparently upgrade to the appropriate sized image.
If once layout happens and the image has been downloaded, start the upgrade request anyway, but at least you'll have a crude placeholder to use for first paint. A placeholder that can be transparantly replaced later, because of the constraint on the images being same-aspect - i.e. you know it will not shift layout.

Doesn't even have to be the smallest defined image in the srcset.
Could be a separate property altogether. Like how <video> has a poster attribute.

Many of the major performance problems with bringing multiple files over the wire have been greatly reduced by HTTP/2 & /3 - it's really just the latency of 'until the image is downloaded' that remains a bother for the first paint and perceived performance. And having a stop-gap candidate that is explicitly marked as such, with the expectation that it will be a very small temporary-use low-quality file to transfer, could go a long way to solving this issue.

[zcorpan]

@rjgotten I'm not sure it's acceptable to load lowest res image first and after layout load the appropriate image. I think that would cause "double download" of all images in the general case, which is generally seen as a bug. Ideally only the appropriate image is loaded, without blocking on layout.

@grigs For new image formats, as far as I can tell the art direction use case is not handled. With the bookstore demo also it's a completely different image, not just a crop. I suppose an image file could in theory contain different images though.

[pc-erin]

@zcorpan Isn't the picture element used for art direction and format handling? You could do art direction with srcset and sizes, but from what I understand it wasn't intended for that.

[zcorpan]

@pc-erin yes, but it's limited to media queries.

[grigs]

@grigs For new image formats, as far as I can tell the art direction use case is not handled. With the bookstore demo also it's a completely different image, not just a crop. I suppose an image file could in theory contain different images though.

Not that it matters for your greater point, but the bookstore demo is the same image with CSS effects applied to it in different contexts.

<picture> likely requires some form of mapping the queries on the sources inside the container to the size of the container and the something on the container itself to the viewport.

So the art direction use case would still require <picture> and <source> options, but progressive downloading of an image could remove the need for sizes and multiple options in the srcset.

It seems that developers have had the most trouble using sizes and srcset correctly. And unlike the problems with developers setting sizes values incorrectly, when I see <picture> misused, it is usually scenarios where sizes and srcset should be used instead.

Web Almanac says <picture> is used 7.7% of the time. So if we can simplify the resolution switching use case, we’re going to simplify over 90% of responsive images.

[eeeps]

@grigs:

Web Almanac says <picture> is used 7.7% of the time. So if we can simplify the resolution switching use case, we’re going to simplify over 90% of responsive images.

• 7.7% of pages used <picture>
• 34% of pages used <img srcset>

But it's complicated; almost all of those <picture>s also use srcset, and I think what we really want to compare is w descriptor vs media attribute usage, and that isn't really derivable from the published data.

But idk 80% "flexible image use case" vs 20% "art direction use case" seems like a reasonable floor, given the numbers we have... especially considering the anecdotal evidence that many <picture><source media>s are actually solving the flexible image use case using a suboptimal tool.