Can you elaborate? Why would you need to put either mobile or desktop first?

Gathering feedback for you: 

http://lists.w3.org/Archives/Public/public-respimg/2012Dec/0006.html

Will respond back once we can answer the question fully.

(In reply to comment #1)
> Can you elaborate? Why would you need to put either mobile or desktop first?

Mobile-First
As it relates to images, mobile-first starts with the smallest-screen layout and adding layout complexity as screen real estate permits generally by way of `min-width` media queries. 

* Where desktop browser support for media queries is fairly solid and mobile browser support is something of an unknown, it ensures that the most sensible styles are served up by default, outside of any media queries.
* In the event that a desktop browser doesn’t support media queries (and no polyfill is in use), the user receives a less complex—but still entirely usable—layout.
* From a developer convenience standpoint, we’re not first coding the “desktop layout” and then overriding all of our custom styles as we build down. That would mean a much larger (set of) stylesheet(s), and a number of additional “where’s this style coming from” headaches.

Mobile first isn't necessarily just about the design of the site, but also the capabilities/limitations that said device has. It is highly unlikely that a desktop, or desktop-like system (i.e. TV browser) will ever be connected to anything but an ethernet/wifi connection. A mobile device, however, could go from such connectivity to 3G/4G connection. Because of this, special considerations have to be made for a mobile device beyond the physical dimensions of an image, such as bandwidth constraints, latency on a OTA connection, etc. Mobile first, then, puts the design/developer in the mindset that the site needs to handle a story set that doesn't always offer the most optimal connectivity options.

Desktop-First
As it relates to images, desktop-first starts with the most complex, large-screen layout, and removing complexity as screen real estate becomes constrained. This is a common approach when retrofitting an existing desktop-centric site for mobile contexts, without the overhead of rebuilding the entire site as mobile-first—`max-width` media queries would allow mobile/tablet focused styles to be bolted on to an existing site with minimal overhead.

A desktop-first development approach, predictably, means putting together the “desktop” layout outside of any media queries, and then reducing the complexity of the layout and tailoring it for mobile in layers via `max-width` MQ. The benefit here is that we would deliver a desktop-centric layout to desktop browsers that don’t natively support media queries—more often than not, it’s for the sake of IE 6/7/8. 

In addition, there may be situations where a responsive layout is being applied in an environment where it’s limited in scope to “tablet-size and up.” In this case, a desktop-first approach may make the most sense, where the desktop layout will still function as-expected on a slightly smaller tablet, but less essential optimizations can be made within `max-width` media queries.

Why would you need to put either mobile or desktop first?
Legacy content might dictate that desktop first approach be taken (implicitly). The use case and context in which the application is used may also dictate the approach taken in designing a solution. 

Relationship to images
With specific reference to images a mobile-first approach would mean serving up the smallest version of your image by default vs the largest.

So what you're saying is you want the src="" attribute to point to the smallest lowest-density image, and the others in srcset=""?

You can do that fine, as far as I can tell:

   <img src="small-lowres.png" ...
        srcset="small-lowres.png 100w 1x,
                small-hd.png     100w 2x,
                large-lowres.png      1x,
                large-hd.png          2x">

The problem is not in defining a low resolution image to be loaded for small screens using srcset. That is indeed possible. 

The problem is in the fact that since `srcset` is defined with max-width dimensions, it cannot match min-width based design breakpoints[1] as they are typically defined with the "mobile-first" approach.

This can be best demonstrated by the following code example:
Mobile first:
-------------
@media screen and (min-width: 30em){
    .img-container{
        width: 60%;
    }
}
@media screen and (min-width: 50em){
    .img-container{
        width: 40%;
    }
}
<div class="img-container">
<img src="small_lowres.jpg"
        srcset="small_lowres.jpg 479w 1x,
                small_hires.jpg 479w 2x,
                large_lowres.jpg 799w 1x,
                large_hires.jpg 799w 2x" /></div>
                    
Desktop first:
--------------
@media screen and (max-width: 50em){
    .img-container{
        width: 40%;
    }
}
@media screen and (max-width: 30em){
    .img-container{
        width: 60%;
    }
}
<div class="img-container">
<img src="large_lowres.jpg"
        srcset="large_lowres.jpg 800w 1x,
                large_hires.jpg 800w 2x,
                small_lowres.jpg 480w 1x,
                small_hires.jpg 480w 2x" /></div>
                    
Mobile-first design and srcset's max-width dimensions definition will likely result in author confusion and non-intuitive need to constantly translate between design breakpoints and image breakpoints.

[1] http://usecases.responsiveimages.org/#design-breakpoints

With a syntax that only allows for `max-width` values, image breakpoints intended to line up one-to-one with layout breakpoints would require the author to do a great deal of manual conversion. Assuming only two layout breakpoints at 32em and 52em, the author would first have to manually convert the em-based values to pixels: 496 and 832, respectively. To then use those values in a `max-width`-only syntax, the image breakpoints would have to be set at 495px and 831px. 

It works, but it’s needlessly confusing where there’s no provable benefit to either authors or users.

> Mobile first:
> -------------
> @media screen and (min-width: 30em){
>     .img-container{
>         width: 60%;
>     }
> }
> @media screen and (min-width: 50em){
>     .img-container{
>         width: 40%;
>     }
> }

This isn't mobile first, it's desktop first: it only supports viewports with a width of 30em (480px) or more.

But you can handle that fine too, as you point out:

   srcset="small_lowres.jpg 799w 1x,
           small_hires.jpg 799w 2x,
           large_lowres.jpg 1x,
           large_hires.jpg 2x" /></div>

I don't understand the use case for doing min-width-based breakpoints. They do the same as max-width as far as I can tell. Why do we need both? Just because media queries happens to have both? That's a bit of a weird reason.

> This isn't mobile first, it's desktop first: it only supports viewports with a width of 30em (480px) or more.

The practice of using `min-width` media queries is called “mobile-first” as it involves building on one’s styles starting with the smallest breakpoints and working up, rather than a set of desktop-oriented styles and simplifying in layers using `max-width` media queries. The reason this is more common is fairly obvious: better to add complexity to a layout as needed, rather than starting with the most complex layout and be gradually override more complicated CSS with styles closer to UA defaults.

It’s worth mentioning that this isn’t a term we’re using for the sake of discussion, but an already established term for a common development approach.

> Why do we need both? Just because media queries happens to have both? That's a bit of a weird reason.

I’ve explained the trouble for authors when using `max-width` alone in the comment above, but to reiterate: where it’s far more common that layout breakpoints will be specified using `min-width` media queries, `max-width` only will require authors to specify their image breakpoints in a somewhat backwards way. It’s needless complexity. Where we’re dealing with a syntax that will be frequently tied to CSS breakpoints: yes, it should have at least a portion of the flexibility used in CSS.

I’d be interested in hearing more about the reasoning behind locking the syntax into `max-width` values, but it seems like unwillingness to extend the syntax in useful ways may be well in “implementor convenience” or “theoretical purity” territory. Again, as I said above: there’s certainly no benefit to authors or users.

As far as I can tell, whether you base things on minimum widths or maximum widths is mathematically equivalent. Supporting both is therefore unnecessary complexity.

There is _absolutely_ authoring benefit to having a simpler language. It removes decisions. You just always do max-width, and never have to chose. You only have to learn one technique. You only have to learn one way to debug the problem.

I don't understand why you'd ever want media queries based on min-width, especially if you're thinking "mobile-first". You design a layout for the smallest devices, then you see at what width it starts getting silly. That's your first media query, which you set for that style, as its maximum width. Then you do another style, and so on. When you give up, you don't bother with a max-width, and you're done.

But anyway, as I said before, there's no problem adding a syntax for min width instead of max width later if it turns out that this is really a pain point.

(In reply to comment #9)
> As far as I can tell, whether you base things on minimum widths or maximum
> widths is mathematically equivalent. Supporting both is therefore
> unnecessary complexity.
> 
> There is _absolutely_ authoring benefit to having a simpler language. It
> removes decisions. You just always do max-width, and never have to chose.
> You only have to learn one technique. You only have to learn one way to
> debug the problem.

Seems strange that media queries themselves didn’t go this same route, then. 

> I don't understand why you'd ever want media queries based on min-width,
> especially if you're thinking "mobile-first". You design a layout for the
> smallest devices, then you see at what width it starts getting silly. That's
> your first media query, which you set for that style, as its maximum width.
> Then you do another style, and so on. When you give up, you don't bother
> with a max-width, and you're done.

Debating common development practices doesn’t really seem productive. This is the most common approach I’ve seen from authors—you are, of course, free to take or leave this information as you see fit. Also, if you’re confident that the approach you’ve described is markedly better than the approach currently taken by the web developer community, outreach and education might be more productive than trying to convince one especially noisy developer. :-)

Here are a few common frameworks advocating this approach:

https://github.com/h5bp/html5-boilerplate
https://github.com/malarkey/320andup
https://github.com/jquery/jquery-mobile

Here are a few especially high-visibility websites making use of this approach:

http://www.microsoft.com/en-us/default.aspx
http://www.starbucks.com/
http://www.time.com/
http://www.bbc.co.uk/news/
https://www.gov.uk/
http://bostonglobe.com

A quick search of the web for “mobile first media queries” or “mobile first development” will turn up a number of articles, presentations, and books that associate `min-width` media queries with a mobile-first approach in the way I’ve described.

> But anyway, as I said before, there's no problem adding a syntax for min
> width instead of max width later if it turns out that this is really a pain
> point.

I imagine there might be where we’re not doing anything to flag values as `max-width` at present. I’m a little curious as to where you would draw the “pain point” line, where you seem unconvinced that this is a common practice at all. This is, for all intents and purposes, a pain point in the proposed syntax now.

> Seems strange that media queries themselves didn’t go this same route, then. 

Media queries were first developed in a different era. I don't know about others involved in its development, but my own thinking on language design has evolved significantly since I worked on MQ, based on what we've learnt over the years.

(Leaving open to study the links in the previous comment.)

(In reply to comment #9)
> As far as I can tell, whether you base things on minimum widths or maximum
> widths is mathematically equivalent. Supporting both is therefore
> unnecessary complexity. 



> I don't understand why you'd ever want media queries based on min-width,
> especially if you're thinking "mobile-first". You design a layout for the
> smallest devices, then you see at what width it starts getting silly. That's
> your first media query, which you set for that style, as its maximum width.
> Then you do another style, and so on. When you give up, you don't bother
> with a max-width, and you're done.

I think "mobile-first" has been slightly misrepresented in this comment thread. The example given in comment #5 does not tell the whole story. This might make more sense:

Mobile first:
-------------
.img_container {

@media screen and (min-width: 30em){
    .img-container{
        width: 60%;
    }
}
@media screen and (min-width: 50em){
    .img-container{
        width: 40%;
    }
}
<div class="img-container">
<img src="small_lowres.jpg"
        srcset="small_lowres.jpg 479w 1x,
                small_hires.jpg 479w 2x,
                large_lowres.jpg 799w 1x,
                large_hires.jpg 799w 2x" />
</div>

> But anyway, as I said before, there's no problem adding a syntax for min
> width instead of max width later if it turns out that this is really a pain
> point.

(In reply to comment #9)
> As far as I can tell, whether you base things on minimum widths or maximum
> widths is mathematically equivalent. Supporting both is therefore
> unnecessary complexity. 
>
> I don't understand why you'd ever want media queries based on min-width,
> especially if you're thinking "mobile-first". You design a layout for the
> smallest devices, then you see at what width it starts getting silly. That's
> your first media query, which you set for that style, as its maximum width.
> Then you do another style, and so on. When you give up, you don't bother
> with a max-width, and you're done.

max-width: 100px =/= min-width: 100px

The max-width breakpoint will style anything 100px wide or below, and is essentially "<= 100" in mathematical terms; min-width will style anything 100px or wider, or ">= 100". When considering speed and bandwidth limitations (as this srcset proposal seems very related to), min-width is the superior choice. 

I think "mobile-first" has been slightly misrepresented in this comment thread. The example given in comment #5 does not tell the whole story. This example might make more sense:

Mobile-First:
------------------------------
.img_container {
    width: 80%;
}
@media screen and (min-width: 30em){
    .img-container {
        width: 60%;
    }
}
@media screen and (min-width: 50em){
    .img-container {
        width: 40%;
    }
}
<div class="img-container">
<img src="small_lowres.jpg"
        srcset="small_lowres.jpg 479w 1x,
                small_hires.jpg 479w 2x,
                large_lowres.jpg 799w 1x,
                large_hires.jpg 799w 2x" />
</div>
------------------------------

As you can see above, a default style is defined (width: 80%) that will apply to all screens until wider than 30em (unless the browser does not support media queries). This means that we can safely assume that, in the case of srcset, the smallest and most bandwidth-efficient image is served up everywhere unless explicitly told differently by media queries.

You cannot take this approach with max-width queries. If you define a default style outside of media queries, you are targeting screen sizes larger than what you've accounted for using max-width queries.

Desktop-First:
------------------------------
.img_containter {
    width: 20%;
}
@media screen and (max-width: 50em){
    .img-container {
        width: 40%;
    }
}
@media screen and (max-width: 30em){
    .img-container {
        width: 60%;
    }
}
------------------------------

The point of "mobile-first" design is not necessarily about mobile devices being more important; it's about whatever is defined as the default style being acceptable on any screen size if media queries fail.

Apologies for the quasi-double post. Please view comment #13 as the full, completed comment.

Wait, so the problem isn't min-width vs max-width, it's what the src="" attribute should be used for in legacy UAs that don't support media queries? What browsers don't support media queries on mobile and what browsers don't support media queries on desktop? If it's really that simple, we can just compare numbers and work out which one we should be intending the default for.

But note that you can use srcset="" today with any value as the default. You just need to make sure you list all the options in srcset="", and then src="" can be something else entirely, it'll just be ignored by srcset="" browsers. Long term, I expect we'll make src="" optional if you have srcset="", as there won't be any need to give a src="" default once all the browsers support srcset.


(In reply to comment #10)
> 
> Here are a few especially high-visibility websites making use of this
> approach:
> 
> http://www.microsoft.com/en-us/default.aspx
> http://www.starbucks.com/
> http://www.time.com/
> http://www.bbc.co.uk/news/
> https://www.gov.uk/
> http://bostonglobe.com

I don't really understand what these sites show. They all seem to handle sizes from width 0 to width W1, width W2 to width W3, etc, up to WN to infinity.

I looked at the CSS for bostonglobe.com, and they seem to use min-width and max-width explicitly on each query (hopefully no browser ever exposes a width of 799.5px...). srcset="" seems like it'd work fine with this.

My biggest concern is that the “max-DPR” approach means users may be left rounding up to unnecessarily large images. On a theoretical—though not at all implausible—screen with a DPR of 1.25x, and several `srcset` attributes targeting 1x and 2x on a page, rounding up to the `2x` sources would mean a significantly larger bandwidth cost with little-to-no perceivable benefit.

We’ve run this through our `srcset` parser using the above-listed combination of factors, just to confirm that this is the case: http://responsiveimagescg.github.io/picture-refimp/demo/?src=default.jpg&srcset=sd.jpg+1x%2C+hd.jpg+2x&vpwidth=1680&vpheight=937&vpdensity=1.25

> I don't really understand what these sites show. They all seem to handle sizes from width 0 to width W1, width W2 to width W3, etc, up to WN to infinity.

While no one is disputing that one can achieve the same effect using `min-width` and `max-width` media queries to achieve more or less the same purpose, what is in dispute is that `min-width` (or “mobile first”) is the more familiar philosophy. As stated previously in the thread, this caught on as a result of wanting to ensure that the most simple layout (which is outside the scope of any MQ, hence “mobile first”) would be delivered to browsers that may not understand media queries.

“Min to max” is the more intuitive approach for web developers, and following suit with the `srcset` syntax stands to put significantly less burden on end users in terms of request weight. If the first point is in dispute, we’d be happy to publish a poll asking for developer feedback.

> I looked at the CSS for bostonglobe.com, and they seem to use min-width and max-width explicitly on each query (hopefully no browser ever exposes a width of 799.5px...). srcset="" seems like it'd work fine with this.

As an aside: while we would sometimes use a combination of `min` and `max` width to target specific modules in layouts, all of our core layout styles on BostonGlobe.com were added by way of `min-width` media queries.

> My biggest concern is that the “max-DPR” approach means users may be left rounding up to unnecessarily large images. On a theoretical—though not at all implausible—screen with a DPR of 1.25x, and several `srcset` attributes targeting 1x and 2x on a page, rounding up to the `2x` sources would mean a significantly larger bandwidth cost with little-to-no perceivable benefit.

Just to emphasize that point, a DPR of 1.25 is far from theoretical. Both Firefox & Blink implement DPR as impacted by the user's page zoom. As such, a DPR between 1 and 2 is likely to happen, even on a standard resolution display, assuming the user has zoomed in on that page in the past.

(In reply to Mat Marquis from comment #16)
> My biggest concern is that the “max-DPR” approach means users may be left
> rounding up to unnecessarily large images.

Can you elaborate on this? I don't understand what that means. Can you give a concrete example maybe?


> On a theoretical—though not at
> all implausible—screen with a DPR of 1.25x, and several `srcset` attributes
> targeting 1x and 2x on a page, rounding up to the `2x` sources would mean a
> significantly larger bandwidth cost with little-to-no perceivable benefit.

Sure. The spec explicitly allows user agents to use the 1x image in that situation, for exactly this reason. I don't see what this has to do with min-width vs max-width, though.


> We’ve run this through our `srcset` parser using the above-listed
> combination of factors, just to confirm that this is the case:
> http://responsiveimagescg.github.io/picture-refimp/demo/?src=default.jpg&srcset=sd.jpg+1x%2C+hd.jpg+2x&vpwidth=1680&vpheight=937&vpdensity=1.25

That is not implementing the heuristics that the spec allows.


> While no one is disputing that one can achieve the same effect using
> `min-width` and `max-width` media queries to achieve more or less the same
> purpose, what is in dispute is that `min-width` (or “mobile first”) is the
> more familiar philosophy.

I'm not saying you're wrong, but I've not seen any evidence of this. You listed some sites that supposedly show this, but as far as I can tell, they don't.


> As stated previously in the thread, this caught on
> as a result of wanting to ensure that the most simple layout (which is
> outside the scope of any MQ, hence “mobile first”) would be delivered to
> browsers that may not understand media queries.

Please see the first two paragraphs of comment 15.


> “Min to max” is the more intuitive approach for web developers, and
> following suit with the `srcset` syntax stands to put significantly less
> burden on end users in terms of request weight. If the first point is in
> dispute, we’d be happy to publish a poll asking for developer feedback.

What's useful isn't polling data, it's looking at how sites are actually written. (People tend to be really poor judges of how they think — you have to look at the concrete evidence to figure it out.)


> As an aside: while we would sometimes use a combination of `min` and `max`
> width to target specific modules in layouts, all of our core layout styles
> on BostonGlobe.com were added by way of `min-width` media queries.

Where would I see this?

mat: ping

From what I understand of this bug, this is fixed by <picture>.

Fixed by `picture`.