Avoid download of smaller media

[nwtn]

This issue came up in the IRC (I think it was raised by @MattWilcox), and I wanted to document it and get some more discussion started. Not everyone agrees it's a problem, so please weigh in. I'm also not sure if/how this should be incorporated into a use case, so thoughts on that would be appreciated too.

Consider a situation where a developer wants a small image for a portrait orientation, and a larger image for a landscape orientation. The images have the same content, they are just different sizes.

Example 1:

    <picture>
        <source media="(orientation:portrait)" src="small.jpg" />
        <source media="(orientation:landscape)" src="large.jpg" />
    </picture>

In this case, a user might load the page in portrait mode, then re-orient their device to landscape. When this happens, the larger image would be downloaded. All is fine and good with the world.

However, if the user loads the page in landscape mode first, they download the larger image first. If they re-orient to portrait, there's no reason to download the smaller image. Since the larger image could have been simply resized, downloading the smaller one is a waste of bandwidth. Right now, we don't have a way to prevent this from happening.

One possible solution would be to stipulate that once a large image has been downloaded, smaller images should trigger a resize rather than a download. However, this causes problems with art direction. A developer may want the smaller image to have different content (e.g. be cropped differently) than the larger image.

Example 2:

    <picture>
        <source media="(orientation:portrait)" src="cropped.jpg" />
        <source media="(orientation:landscape)" src="full.jpg" />
    </picture>

In this case, an orientation change in either direction should trigger a download. That means we can't stipulate that a smaller image shouldn't be downloaded.

Another solution might be to group sources with identical content, e.g. with a name attribute.

Example 1a:

    <picture>
        <source name="full" media="(orientation:portrait)" src="small.jpg" />
        <source name="full" media="(orientation:landscape)" src="large.jpg" />
    </picture>

In this case, the browser would know based on name that the two sources have identical content. It would then know that it could safely scale down an image, rather than downloading a smaller version. When loaded in portrait and re-oriented to landscape, the larger version would still be downloaded. When loaded in landscape and re-oriented to portrait, the browser would resize the larger version rather than downloading a new file.

(This might also provide a nice added benefit when switching from portrait to landscape: a scaled-up version of the image could be displayed until the download of the large version is finished.)

Example 2a:

    <picture>
        <source name="cropped" media="(orientation:portrait)" src="cropped.jpg" />
        <source name="full" media="(orientation:landscape)" src="full.jpg" />
    </picture>

In this case, the browser would know based on name that the two sources have different content. It would know that an orientation change in either direction required downloading the appropriate source, and that it couldn't simply resize the image.

[igrigorik]

If you want different images based on-art direction, then specify different images. Further, the browser is unlikely to defer the loading of the alternate orientation image until that happens - instead, it will be treated as a low priority resource and will be downloaded at the end of the initial page load. Doing on-demand loading as core behavior would only make the overall performance worse - especially on mobile networks, where negotiating the radio link can take ages. Note that this is the same behavior as implemented for CSS stylesheets today across all browsers...

1. If you want to rescale the image based on orientation change: you can already do that with existing tools
2. If you want a different image based on orientation, then media queries can already accomplish this
3. If you want to override both behaviors, then you can dynamically inject an image tag based on some interaction

In other words, this is a no-op.

[anselmh]

I agree w/ @igrigorik this is no real problem.
You still should use img for images not changing or you have to set your media-queries in a way that does not change the source. That is possible right now, right.
Otherwise if you want to have a different crop it should download both image-sources.

BTW @nwtn: Your example is not correct. You are talking about the name attribute but show the id-attr. Please fix this to avoid confusion.

[nwtn]

@anselmh thanks, will correct.

[MattWilcox]

Hi,

This is almost right but not quite.

My point was about the download behaviour when a media query crosses boundaries and a lower-resolution resource is "requested".

The scenario is this:

You've visited a website at a large window size. You've got a bunch of picture elements, they've matched a media query, you've downloaded the higher resolution version. You now shrink the window and cross a query boundary. What's the right thing to do now? Because...

... if the picture is not art directed, i.e., it's just a re-sized version of the larger file, then there is no point at all in requesting a new image. It would be much more efficient and (infinitely) faster to simply scale down the one that's already in memory.

... if the picture is art directed, it will need to download the smaller version.

The problem with choosing which behaviour is more optimal is not one that can be automatically arrived at with picture in its current state. The author knows which use case they're answering for any given image with their picture element.

If we blanket dictate that the element should always download the newly matching image then we're likely making the majority of pages slower then they need to be (when crossing boundaries), and costing bandwidth which has zero practical use. For any non-art-directed picture. Which, I feel, is likely to be quite a lot.

The proposal in IRC was to add some sort of flag to change the behaviour of the browser per picture element. e.g.,

<picture type="art-directed"> ...
<picture type="scaled"> ...

and default to whichever is the most likely use of a picture element in general.

[MattWilcox]

PS: I don't think this use case can be bunched in with the "the browser can download additional assets after page load automatically" thing. Which i feel is terrible behaviour in this case - there could be half a dozen potential matches, and we do not want the browser downloading all of them after page load just in case one matches later. That's horrendously wasteful.

[marcoscaceres]

IMO, the right thing to do is whatever the media queries that match says to do. Please lets not over-complicate and over-engineer this (i.e., apply the KISS principle). CSS does not try to be overly clever, and adding some clever model will just result in unpredictable behaviour, confusion, and frustration ("i.e., why is my image not showing up?! browser is broken!!!!!").

[yoavweiss]

@MattWilcox We probably don't want to use type for that (it's best to save type as an image format indicator). Any other attribute that makes sense (e.g. usecase) will do. Otherwise - great writeup of the IRC discussion.

The only point worth emphasizing: real users may not change their browser window dimensions that often. The main exception for that are orientation changes.

I'm not sure how often that actually happens and how much bandwidth will be saved by such optimization.

[igrigorik]

@MattWilcox I understand your concern over wasted bytes, but it's important to recognize that doing on-demand downloads can (a) lead to worse off UX, and (b) will definitely lead to much worse performance profile. In fact, (a) and (b) are intertwined.

On a mobile connection, which is exactly where you would want to save the bytes, the act of bringing up the radio can consume up to several seconds + plus the time to make the request and fetch the data. Hence, you rotate your screen, and then you're looking at an empty image for several seconds - how's that for a good UX? Further, this is also very wasteful for the battery. The general recommendation for mobile is to download all resources at the beginning when the connection is hot, and then turn off the radio. This is how browsers behave today for all media queries, and this is highly unlikely to change.. (this is a separate battle, and one that you don't want to get into).

As @marcoscaceres mentioned: KISS. You can still get the dynamic behavior you want by introducing some JS code, if you really want it.. But you will run into the performance gotchas I've mentioned.

[Wilto]

It’s fairly uncommon that the average user will visit a page and then reorient the device—at least, by comparison to visiting a page in a single orientation. Say we have a thousand users visiting five page apiece—each containing a picture element with only one breakpoint—leaves us with five thousand assets downloaded “just in case” that the user may never see.

The very first objective we set out to solve was reducing redundant requests for non-essential assets from which users may see little or no benefit. If the proposed element ends up requesting three image sources regardless of whether they’ll ever match for their device and we leave it at “well, just use a custom solution,” we’re no better off than we were with the img tag—right down to all the same issues with prefetching that led us here.

It will be a worse performance profile, yes, but only for those users that reorient their devices mid-browsing—and even then, only once. But the number of users apt to do that is invariably going to be smaller than the number of users simply visiting that page, and we aim to do the most possible good with this element.

[anselmh]

It’s fairly uncommon that the average user will visit a page and then reorient the device—at least, by comparison to visiting a page in a single orientation.

Sorry to interrupt you here. This is a common and often used practice on tablet devices. On mobile devices this is a non-issue. But I don't know if that is a real problem. I personally can live with this.

Say we have a thousand users visiting five page apiece—each containing a picture element with only one breakpoint—leaves us with five thousand assets downloaded “just in case” that the user may never see.

So you mean to download landscape and portrait on such devices? No, that is a no-go. Never forget the bandwidth and mobile traffic limits. Also performance is very bad when UA has to download at least 2 images instead of one.

[Wilto]

Yeah, that’s the case I was making, @anselmh—downloading assets for both orientations (not to mention every other listed source, such as ones intended for 1000px-wide displays) is a non-starter. I understand that requesting all available sources may result in better perceived performance for those users that do re-orient while browsing, but it does so at a cost to every other user visiting that page.

[scottjehl]

I agree with @Wilto.

The main point of picture and the RICG's work was to allow authors to specify a single image to be requested and shown in a particular context, without requesting any additional overhead. This isn't only a performance concern, though it was intended as such. Much of the world's mobile users (including me) have data plans that are affected by data usage, either by limiting network speed after a certain amount of data is used, or more commonly, capping access altogether to a certain amount per month.

As screen dimensions and definition continues to rapidly change, authors will continue to add picture sources to deliver an optimal size/crop to any viewport/definition combination that may view their site. Instructing each device to load all of the assets available within a picture element, regardless of their applicability to the environment, can't possibly be better for users than requesting the one image that'll likely ever be needed. We have this same issue with overhead in CSS, and yet CSS at least has the benefit of concatenation and gzip compression.

If a browser doesn't negotiate a single appropriate request per picture element, I'm not sure there's much value in a native picture element over existing approaches that already work today. JS polyfills with a on-demand fetch pattern have been serving users well on major sites for some time now, but they lack any exposure to prefetch, which is something native picture could provide.

[MattWilcox]

It seems that picture needs smarter behaviour based on the use-case for each picture element.

In cases where it's not art directed, and you've already downloaded that largest asset the device can ever display, then no further processing should happen. Never request anything else; just scale what's in memory down.

In cases where it's not art directed, and you've downloaded a smaller image than the maximum the device could display, then interrogate a browser preference: download on demand, or pre-fetch after page load.

In all cases where it's art directed, consult the browser's preference (download on demand, or prefetch).

These behaviours allow the user to decide what is most appropriate for them: saving bandwidth at the cost of re-loads upon transition, or get smoother transitions at the cost of bandwidth.

In my opinion, it is a complete no-go to have picture auto download every defined asset. That does not answer the use case of the element in the first place, in fact it makes the situation far worse.

It should also be noted that there's never any point pre-fetching an asset the device could never support in the first place (I don't know how the algorithm might handle that at the moment).

[scottjehl]

Whether a source is art-directed or not will never be detectable by the browser, and that's okay.

A simple rule of only requesting the last applicable source element within a picture element whenever it is parsed is all that is needed here.

[anselmh]

Fully agree.

[Wilto]

+1 here.

[beep]

A simple rule of only requesting the last applicable source element within a picture element whenever it is parsed is all that is needed here.

+1 from me. I’d be comfortable handling any subsequent updates myself on the client.

[scottjehl]

+1 from me. I’d be comfortable handling any subsequent updates myself on the client.

Ideally, I'd expect a client to automatically re-parse for a more appropriate source after any environmental change that would cause another media query to become applicable, such as orientation change, viewport resize, projectors or print @media changes, etc.

[beep]

Sorry, was posting in a slightly uncaffeinated state.

Ideally, I'd expect a client to automatically re-parse for a more appropriate source after any environmental change that would cause another media query to become applicable, such as orientation change, viewport resize, projectors or print @media changes, etc.

Wholeheartedly agreed. +1 to this.

[marcoscaceres]

Ideally, I'd expect a client to automatically re-parse for a more appropriate source after any environmental change that would cause another media query to become applicable, such as orientation change, viewport resize, projectors or print @media changes, etc.

I also wholeheartedly agree. +1 to this. And it's also what is currently in the spec and in the use cases and requirements document:

1. The solution MUST afford developers the ability to match image sources with particular media features and/or media types - and have the user agent update the source of an image as the media features and media types of the browser environment change dynamically.

This is the behavior followed by CSS backgrounds, so it stands to reason that picture will behave the same way.

Please see (open network inspector, resize the relevant viewport): http://jsfiddle.net/UWsGf/

[yoavweiss]

Just to add that any UX lag on orientation changes (resulting from mobile data wake up times & re-fetching) can be compensated by showing the resized resource that was already downloaded, until the relevant resource arrives.

@scottjehl - current prototype implementation downloads the first applicable <source>, similar to <video> (and unlike CSS). Is there any advantage to downloading the last applicable one?
Also - a browser can tell if a <source> is art-directed or not if the Web developer will indicate it (using an attribute). Whether it is worth the hassle is a different question.

[igrigorik]

I understand the direction and the sentiment, but it's not going to happen: the browser will download all of the specified breakpoints given in the markup on the initial load. This is nothing new, this is how all CSS + breakpoints are handled today, and changing this will require monumental changes to all specs and clients. Further, due to how preloaders are architected.. the browser won't even know which break points to apply until the document is constructed, which runs the risk of blocking the entire page load due to a deferred breakpoint evaluation - not going to happen.

Put differently: you won't get the behavior you want based on media queries. But, you can achieve the desired results through other means.

These other means are (a) scripting on the client, or (b) server-side adaption of the document and / or the resource.

[marcoscaceres]

@igrigorik it's hard for us to understand your position without some running code. I provided you with evidence that this, in fact, does not occur with CSS backgrounds (http://jsfiddle.net/UWsGf/) - which are the closest cousins to picture. Can you provide evidence to the contrary?

[yoavweiss]

@igrigorik Did you have a chance to take a look at https://github.com/yoavweiss/RespImg-WebCore/ ?
It's a Chromium WebCore fork implementing 'picture' without dowloading all the resources (only the first one which MQ applies, from within the preload scanner)

[scottjehl]

the browser won't even know which break points to apply until the document is constructed

Doesn't webkit's preload scanner already handle this well when fetching CSS links with media attrs? I thought your article on CSS proved this to be the case.

Also, @yoav's working webkit picture prototype works with prefetch, as far as I know. He can confirm.

As for first or last source, I prefer last because it aligns with mobile-first media queries, but as long as one resource is fetched, that's debatable.

On Oct 29, 2012, at 6:36 PM, Yoav Weiss wrote:

@igrigorik Did you have a chance to take a look at https://github.com/yoavweiss/RespImg-WebCore/ ?
It's a Chromium WebCore fork implementing 'picture' without dowloading all the resources (only the first one which MQ applies, from within the preload scanner)

—
Reply to this email directly or view it on GitHub.

[igrigorik]

@marcoscaceres the running code is every browser out there - feel free to check, every browser will download all breakpoints of your CSS files. For CSS backgrounds, I need to take a closer look at existing logic behind that - my guess is that there is a difference here between evaluating the rules within the DOM context and within CSSOM.

Not directly related, but some discussion on CSS handling in webkit:
http://www.igvita.com/2012/06/14/debunking-responsive-css-performance-myths/

@yoavweiss good stuff! Based on past threads, I've got the strong impression that pulling the MQ evaluation into preloader is a non-starter, as it would actually degrade the overall performance. Have you discussed this with anyone on Chromium core? Regardless, kudos for experimenting with it.

@scottjehl no. The preloader specifically doesn't evaluate any media queries. Instead, it simply does a dumb check and assumes that anything that has a complex query will evaluate to true (heuristic, but works). An exception being a "print" stylesheet, which is still downloaded but at a much lower priority. The tradeoff here is: the preloader (a) doesn't have the context of the document, (b) we can't spend much time in preloader (it has to be simple).. hence why we keep it simple and heuristic driven.

[Wilto]

@igrigorik

There was a great deal of discussion around evaluating media queries at preload, and it sounds like you might be thinking of tailoring asset delivery to suit the layout or picture’s containing element—we definitely wouldn’t be able to deal with that (as that information wouldn’t be available) and we don’t aim to. It was confirmed several times that information about the media type, screen/window height and width, etc. will all be available at the time of prefetching, and @yoavweiss’ experiments confirm this—we’re not introducing any delays into the preload scanner while waiting for information to become available.

I think we’re needlessly conflating the way media is handled on link and how it would work within picture. I could definitely see a case for requesting the entire set of stylesheets to avoid a FoUC between specified breakpoints, but that wouldn’t be an issue here—we would simply display the previously requested image until the replacement began to load. With picture we’d also be dealing with a much, much larger potential bandwidth cost to every single user that visits the page, and a significantly reduced benefit by comparison to avoiding a FoUC or partially-skewed layout. I don’t think all the same reasoning applies here.

[igrigorik]

@Wilto can you clarify how media on link and on picture are any different? It's the same CSS media query, and the syntax leads me to believe that any media query could be used in both cases. Perhaps I'm missing something obvious here (wouldn't be the first time ;-)).

Also, I'm not sure I follow the "we'll display the old image until..." - what you've just described is FOUC. Would the page just flash and replace the image with a completely different image - this seems like jarring experience. Finally, I hear ya on the bytesize argument; I would never argue against saving bytes. Having said that, based on performance of mobile networks, and how the radio works, the on-demand loading is actually an anti-pattern on mobile! Android, ATT, and others are all singing the same tune nowadays: download all of your resources upfront, shut down the radio.

[marcoscaceres]

Hi, all. The discussion is getting circular, and the tone is not one in the spirit of collaboration; so I'm sorry, but I'm closing down the bug. Once we actually have an implementation that we can file a bug against, this is speculation and grand standing.

Having said that, I think @igrigorik has raised some very valid issues and has set a challenge to prove him wrong (a good thing!). However, this is not the right time to be having this discussion. We will have to return to this, but only once we make some more progress on an implementation.

An important take away from this is that all bugs MUST have a test case and be against running code to be considered valid. Otherwise, we risk turning GitHub into a mailing list - and that would be really bad.

@igrigorik, I kindly ask you give the implementation a chance to mature. What I would be really helpful would be if you can create a set of test cases for this. Are you willing to help with that? That way, we then have a real set of code to talk around.

[igrigorik]

@marcoscaceres I'm not sure what you have in mind by test cases here.. So far, I'm not convinced that the current browser behavior, while not perfect, is far from what we actually want: the test case is no-op. :-)

Having said that, will try to gather more feedback from the team here at Google.

P.S. IMO, implementing without any consensus on the behavior seems a bit backwards..

[anselmh]

A test case only works with a somehow working implementation. It is nearly impossible to measure performance issues here, that is up to the UA vendors. But some of them assured it works (WHATWG mailing list).
I planned to do a W3C test against picture-element but not sure when I have the time to write that. Hopefully this week.

[marcoscaceres]

@igrigorik would appreciate any further feedback from Google. Also, please don't view the prototype implementation as representing consensus: it's specifically designed to allow us to test crazy ideas, make lots and lots of mistakes, and fail badly so we can actively and rapidly learn from those mistakes (and not codify the mistakes in the spec... It's why it's a "prototype", right?).

This is a rapid and highly iterative process. Consensus will only come once we have sufficient data/tests/running code that shows the solution works for the use cases (I.e., does not suck on mobile network and actually works in the manner you describe - which I think we all agree with). Anyway, I know you know all this already. Sorry again to have shut down discussion, but I really think @yoavweiss needs a chance too see what he can come up with (and for us to keep throwing realistic tests at the prototype).

[marcoscaceres]

But some of them assured it works (WHATWG mailing list).

@anselmh if you can find a pointer for the above, that would be helpful.

[yoavweiss]

@igrigorik I'd love to talk to people from Chromium core (or any other browser vendor) regarding this. Feel free to ping me on twitter (same username) or mail (yoav at yoav . ws). I did not observe any performance impact of the fact that I run full MQ evaluation in the preload scanner. I'm using the document's Frame and RenderStyle to do that (I'm getting the RenderStyle through styleResolver::styleForDocument).

@scottjehl : @igrigorik is right that currently stylesheets are not getting full MQ evaluation. However, they can get that, using the same technique I used for <source>. I'm contemplating a WebCore patch that does only that.

[andydavies]

(Edit: should have refreshed my browser before posting this as it says similar to what Ilya says above ...)

@marcoscaceres in the case of CSS, a browser will download all the external CSS regardless of whether the MQ is applicable or not (some browsers will defer the load of external CSS that cannot ever match the current viewport until the end of the page) - this is what I think @igrigorik is driving at.

WHATWG spec for <link> element

The resources referenced within the CSS are then downloaded when the MQ is applicable (this is what your test case shows). Don't know the exact details but pretty sure this isn't handled as part of the HTML parser in the way <picture> would be - that said ever the <link> spec allows for infinite deferring of download where MQs aren't applicable.

Whether there's a case where the background images are downloaded anyway I'm not sure but browser CSS behaviour isn't as clearly defined as HTML behaviour though I think Tab Atkins and others would like to fix that.

One thing that's not clear to me reading the spec is what viewport do the <picture> MQs correspond to - the document viewport or the space available for the image?

[yoavweiss]

@andydavies the MQs correspond to the document viewport - which is why we can prefetch resources based on these MQs before rendering actually started.

[marcoscaceres]

@andydavies thanks for the clarification. I totally understand that problem (and it might turn out to be undoable), but I don't want us to not at least attempt to work around it in the prototype. We are defining something new here and it would be a shame to not at least try (even if we get nowhere).

[anselmh]

Another thing here to throw in after I just merged the print-demo in. What happens if a page is printed? It should then download the image with print media-query on demand IMO.

[igrigorik]

@yoavweiss the MQ's correspond to UA viewport right now. But, webkit just landed support for "CSS Device Adaption" which is explicitly pointing to deferring MQ evaluation until the viewport rules are applied:

The rationale for using the viewport descriptors obtained from applying the @Viewport rules for evaluating media queries for style rules, is that media queries should match the actual viewport that the document will be layed out in and not the initial or the one specified in the UA stylesheet. Consider the example below given that the UA stylesheet has a viewport width of 980px, but a device-width and initial viewport width of 320px. The author has made separate styles to make the document look good for initial containing block widths above or below 400px. The actual viewport used will be 320px wide, and in order to match the styles with the actual viewport width, the viewport resulting from applying the @Viewport rules should be used to evaluate the media queries.

http://dev.w3.org/csswg/css-device-adapt/

With the above, the viewport rules may reside in CSS file which must be first downloaded and parsed before we can make any decisions about the media queries. Which doesn't play nicely with the preloader.

---

Independent of all of the above, let's take a step back, as I think there are actually two different problems here:

1) Certain break points may not apply at load time, but can be applied at later time (ex, orientation). Question is: how should these resources be scheduled?

I believe the answer is: the ones that apply immediately should be downloaded as a critical resource. Resources that may be applied later should be downloaded at lower priority but as part of the initial load. This is, in fact, the optimal loading behavior for mobile devices. This also avoids funky FOUC behaviors later.

2) Certain break points not not apply ever. For example, desktop breakpoints on a mobile device. This is where we need to figure out how to avoid the extra bytes. Going from smaller to larger form-factors is painful.. Note that the other direction, desktop to mobile, is not nearly as painful (high bandwidth connections).

There are many different ways to address (2): server-side adaption, client side logic, browser smarts.

• Server-side is a feasible and workable solution but requires additional data from the browser to be reliable, ex: client-hints
• Client-side logic introduces additional latency delays, but works today
• Browser smarts.. is something like MQ, expect this is still a complicated subject: how do you know to rule out certain rules entirely when you know nothing about the viewport?

It could well be that a combination of server-side and client-side is the KISS solution.

[yoavweiss]

@igrigorik - Thanks for that comment!

@viewport (in its external CSS file form) does pose an obstacle I didn't consider when it comes to viewport width based MQ & preloading. We need to think of the optimal way <picture> & @viewport can co-exist.

Regarding resources that will probably be applied later (in events such as orientation change), I agree that there are tradeoffs to both "download on-demand" & "download everything in the initial load" models.
If "Flash of lower resolution image" (FOLRI?) proves to be a problem, I believe this is something that can be optimized later on by the browser, probably with a user-preference (e.g. "I'm roaming, download only necessary resources")

[igrigorik]

Heh, FOLRI - I like it.

Honestly, I don't think handling "FOLRI" is a decision that can be made by the browser. It's the person authoring the content that should be making this decision - in some cases it may be "ok" to have this behavior, in others it may simply be unacceptable. In other words, this is decision that needs to be made by the person creating the content, a user override is meaningless in this context. With that in mind, this starts to feel more like a client-side problem:

• I can get instant behavior by letting the browser do the instant switch based on preloaded data
• If I want the fade effect (or whatever other transition you want to dream up), then drop in a client-side library to listen to orientation events and go crazy on any behavior you want

Note that you can only get the first behavior by letting the browser preload the images from the start (and do so efficiently).

[Wilto]

It sounds like this is a larger conversation that we’ll likely have to take up after TPAC. @viewport is definitely a major consideration in all this.

I feel strongly that forcing a user to download the entire set of images sources within a picture element—some/many of which may never apply to their context—is a far worse solution than not having a picture element at all. Honestly, I’d hate to have been partially responsible for any “solution” that sends hundreds/thousands of kilobytes of inapplicable image files to every single user on every single page on the web that contains a picture element. It’s terrifying to think of the bandwidth impact picture would have on the web at large if it should become widely adopted in that form.

As described above, picture would leave us with a solution that only has merit so far as developer convenience and does so at a tremendous potential cost to our users. We’d be better off using existing responsive images solutions like Picturefill, which avoid this additional overhead.

Let’s regroup and discuss this further on the mailing list, once RICG members are back from TPAC.

[igrigorik]

@Wilto sounds good. I'm 100% with you on the bandwidth concern. With that in mind, don't take the concerns that I've raised as an argument against <picture> - the rationale behind it, and the motivation make sense to me. We just need to figure out the right mechanism to trigger the downloads. MQ's may or may not be the right answer.

[baamenabar]

On the issue of avoiding the download of smaller media. It can be completely avoided using min-device-width and max-device-width wich will ignore de device orientation, so you can set the image to the widest orientation or the most narrow, what ever fits you better.

I haven't thoroughly tested, but in theory it should work.

[marcoscaceres]

@baamenabar it would be great if you could put together a demo of that, so we have another data point.

[baamenabar]

OK, I did a demo, could't figure out how to do a gh-pages branch of a branch, so I uploaded to my server.

http://medula.cl/temp/no-folri/

and the repo is here: https://github.com/baamenabar/ricg-demos/tree/no-folri

Did testing on a Galaxy SII and an iPad 3 on various browsers, as a proof of concept it works.

[baamenabar]

Firefox on Android seems to ignore min/max-device-width, but I'm pretty sure I'm one of only 5 regular users of that browser (Too bad because it is very good).

[anselmh]

Thanks for this demo, we should take that into our demo-space on http://responsiveimages.org/demos/ – @baamenabar are we allowed to do that? Can you send us a pull-request to our repo https://github.com/ResponsiveImagesCG/demos/ ?

Unfortunately the Firefox for Android problem can be confirmed by me but this is a problem of the UA. It works on Chrome and WebKit browsers I tested on mobile. Think if we can figure out where the problem is, we can file a bug report on Firefox for Android to get that fixed.

[baamenabar]

Of course you can do that, I've just send a pull request I hope it's done correctly (I'm new to this social code versioning thing).

Should I do it on the polyfilled branch instead?

About the Firefox for android issue, I'll make a simpler test to see how far the problem goes.

[anselmh]

@baamenabar no it's correct in gh-pages. Will review and merge if valid.

[marcoscaceres]

Closing. Thanks everyone for the very useful information.

[yoavweiss]

To sum up:
Once we accept that picture is for art direction & srcset is for resolution switching, this is a non issue.
Different <source> MUST be downloaded if media query conditions changed
Different srcset candidates should be downloaded unless the browser heuristically decides it is not necessary.