Summary of use cases and requirements

This post is from the public mailing list where Kornel Lesiński has summarized this.

DPI/optimization problems:

1. Regular DPI images look bad on Retina iPad.
2. Regular images look bad on Retina iPhone if zoomed in, and on desktop screens too when large zoom factor is used.
3. Regular images sometimes look bad when printed.
4. High-DPI icons/line-art images scaled down are blurry.
5. High-quality images take long time to load, especially on slow connections.
6. High-quality images may be expensive to load on mobile connections.
7. Image galleries with lots of large images (e.g. worth1000 threads, Tumblrs) strain phones’ memory (cause other tabs to be “flushed” or don’t load completely).

Layout problems:

1. Images designed/cropped for wide screens are poor fit on portrait screens and vice versa.
2. Images designed for large screen lose too much detail when scaled down to physically smaller screen (a differently cropped image could be more readable, e.g. portrait instead of a group shot).

Requirements:

1. No wasted bandwidth.
2. No extra HTTP requests.
3. No complex or overly verbose markup.
4. Hard to get wrong (should survive mindless copy&pasting from w3schools’ misinterpretation of the feature).
5. Should not deteriorate badly over time, even when misused (e.g. like User-Agent strings, which poorly sniffed caused browsers to lie, which caused more sniffing and lying).
6. Needs to work with new/unusual types of networks and screens, and should not get in the way of browsers innovating in this area.
7. Easy to deploy on existing infrastructure (shared hosting, CDNs).

Nice to haves:

• Easy to get right (non-geeks who “just want their blog to look nice” should be able to figure it out).
• Allow users (user-agents on their behalf) to influence choice of quality/bandwidth trade-off (e.g. an impatient person with poor vision may not give a damn about Retina images. An RSS reader preloading feed in background or HTML5 offline cache may want high-res even on slow network).
• Allow authors to say when quality is most important.
• Be familiar to users of current solutions, follow existing practices where possible.
• Achieved quality isn’t worse than the best UA/device can provide.

Jad Sarout answered:

The only way to cater for all these (sorry, I am just chiming in, never participated before so if I derogate to rules or etiquette, please tell me), is to have the browser handle most of it. Also, please bear with the awkward English, I’ll try to be as clear as possible.

I would imagine something like the automated call for favicon. So the browser decides what to do (try to load favicon from the root) but we can influence the behavior through meta-tags and css.

Let’s say that for a file (lowest possible resolution) “image.jpeg”, it would be expected that the browser could ask for “image.jpeg.medium”, “image.jpeg.large”, “image.jpeg.landscape” and so on (mind you, these names do not match to the user’s resolution, but standards, so an iphone browser could very well request the “image.large.jpeg” if its browser was set on “high bandwidth”. This said, they should probably be numbers so we can add to them later).

In order to avoid unnecessary requests, the browser would attempt the loading only if a specific meta-tag is present.

We would have to invent a new sort of CSS rule, that would allow:

1. To disable these calls on certain images (let them be disallowed by default, and allow them for certain classes only)
   img.oneResolution{
        responsive:none;
   }
2. To specify how the rules work (it would serve to rename the defaults; or maybe you want to serve the same image “$imageName.big.jpg” for a certain number of requests)
   .img{
      responsive: 320(attr(src)’.small’), 420(attr(src)’.small’),640(attr(src)’.big’), 960(attr(src)’.big’), none// next resolutions get the last highest one.
   }
3. To refine behavior, for example:
   @media only screen and (max-device-width: 1200px) and low-bandwidth{
       img{responsive: attr(src).medium}
   }
   @media only screen and (max-device-width: 1200px) and high-bandwidth{
       img{responsive: attr(src).large}
   }

Benefits:

• On the server side, this could be handled in a variety of ways: automatic image generation and caching, user uploading several versions, etc…It leaves full flexibility on that point; If the feature is partially implemented, one could do a regex on server level to redirect calls to “image.jpeg.big” to “image.jpeg.medium”.
• On the browser, it is also very flexible and it is up to each vendor to decide how to deal with this, open options to the user, decide smartly what to do, or use plugins (for example, firefox might try to do this intelligently by default, but plugins would expose a slider that lets the user decide how to handle this). Also, full backward compatibility with no added markup. The img tag stays untouched.
• Full separation of concerns: The content is specified in the markup, refinement if presentation CSS.
• Very easy to implement and noob-ready: if you are not aware of the feature, just upload your biggest image and let your CMS handle the requests. Sort of complex for the CMSes, but a lot of similar solutions are already in use since years and there is almost nothing to change, just modify the regex to stick with the spec. All important (and less important) CMSes have that sort of feature.
• It is even easy to implement this on server-level. No additional http requests:
• browser-responsive-aware and server-not-responsive-aware:
• meta-tag not present, browser behaves as default
• browser-non-aware and server-aware: no requests, server serves
• the default image specified in the img tag
• browser-aware and server-aware: the browser only requests the
• correct image, and not the one in the markup.
• The only case in which there are wasted requests is if the server specifies it is responsive-aware, but the website is not. In which case the browser will request images that don’t exist. This could be a problem, but it can be solved in a variety of ways: specify “responsive:none” in CSS, include a meta-tag “not-responsive”…
• Easy to pollyfill

Drawbacks:

• Much larger space needed per site (but that’s the case for all solutions)
• Difficult to imagine the CSS “responsive” rule in a way that it reads easily and allows for all use-cases (and future ones), as well as deciding on the default naming of the images.
• Solely Dependant on browser adoption, and it is not an easy task for them (the quality of the algorithm that decides which image to load is a cornerstone, if badly implemented, nothing will work).

Am I way out of my league or is what I am saying making any sense?