Proposal

What if media queries and breakpoints could stay in the .css file?

What if the image source was chosen based on the min-width, max-width, min-height, and max-height of the <picture> element instead?

Media queries would apply size restrictions to images based on css classes.

The element itself would only be responsible for providing a collection of URLs, described by their size, in pixels, and their mime-type.

The UA would be able to choose the best match based on the pixel density muliplier and available bandwidth.

This means more work for RICG, as we need to specify a reccomended selection algorithm, but I believe that's something we need to do anyway.

Old syntax

<picture alt="Description of image subject."> 
  <source srcset="small.jpg 1x, small-highres.jpg 2x"> 
  <source media="(min-width: 18em)" srcset="med.jpg 1x, med-highres.jpg 2x"> 
  <source media="(min-width: 45em)" srcset="large.jpg 1x, large-highres.jpg 2x"> 
  <img src="small.jpg" alt="Description of image subject."> 
</picture>

New syntax (css)

@media (min-width: 18em) picture{
  max-width:320px;
}
@media (min-width: 45em) picture{
  max-width:800px;
}

New syntax (html)

<picture alt="Description of image subject."> 
  <source src="small.jpg" width="300" height="200" />
  <source src="med.jpg" width="600" height="400" />
  <source src="large.webp" width="1200" height="800" type="image/webp" />
  <source src="large.jpg" width="1200" height="800" />
  <img src="small.jpg" alt="Description of image subject."> 
</picture>

Benefits

DRY and separation of concern - breakpoints do not have to be specified in-markup
Fewer image variations have to be described - pixel density is handled intrinsically (large is typically a hi-res version of medium, etc)
No complicated parsing. One value per attribute - simple!
Highly forward-flexible - We can invent CSS properties such as 'picture-select: favor-large` to provide browsers with suggestions or overrides (logos, for example, we might prefer to always be highres, while content pictures can degrade on slow connections, etc). Browser vendors have shown CSS is much easier to innovate with than markup.

Prefetch considerations

We know browser vendors would prefer to prefetch images before CSS downloading completes, but I propose that goal be suspended for a moment. Delaying the prefetching of multi-source images until after css (or a portion thereof *) has been parsed would offer many advantages; I also don't see how the UA would be able to make an intelligent choice concerning resolution until layout has been somewhat established.

* An otherwise null-op CSS property (like "allow-picture-select: now;" could signal to the browser when image source selection can safely be made. I don't like the idea of such a property, but it could resolve the prefetching issue if it's sufficiently important, and we could suggest that picture rules be placed at the beginning of CSS, like we do with fonts.

Addressed use-cases

See the Use Cases document

3.1 Resolution-switching - UA knows the multiplier, and can evaluate whether to apply it or not
3.2 Art-direction based - Full control based on element max-width and max-height from CSS media queries
3.3 Design breakpoints - Much better support than existing proposal, as they go where they belong - in CSS
3.5 Relative units - inherently addressed
3.6 API to manipulate sources - Vastly simplified vs. original proposal.
3.8 User control over sources - not affected

Nearly addressed use-cases

3.4 Matching Media Features and Media Types
4.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.

Solutions to 3.4 and related 4.1

This solution proposes resolution-based selection as the primary mechanism instead (or in combination with - see below) of a more generic 'media feature' query.

Look at the media query spec.

All the media features are essentially resolution indicators. Combining them into sane rules is not simple, and duplicating those rules for every element (versus in a CSS file) does not make sense.

Markup authors will be more successful when CSS developers can provide them with a handful of classes, than when they attempt to structure media queries themselves. The new solution is something a WYSIWYG editor could support, while the old solution would be excessively difficult to implement without a CMS module of some kind.

The only media features that don't end up as resolution indicators are:

4.8. color
4.9. color-index
4.10. monochrome
4.12. scan
4.13. grid

I cannot invent any use-cases for scan, grid, or color-index.

If, in the future, 48-bit color becomes the norm, then I could see a use case for color

monochrome is the only non-resolution media query with a current, valid, use-case, AFAIK.

As mentioned in the use-case specification, many images require completely alernate imaging (and as such, will likely require alternate alternate text and perhaps alternate associated captions).

I wonder if this single use-case deserves such an inflated and over-generic <picture> element?

lilith/alternate.md