W3C home > Mailing lists > Public > public-respimg@w3.org > April 2012

Re: Specific use-cases

From: Kornel Lesiński <kornel@geekhood.net>
Date: Sun, 15 Apr 2012 16:51:21 +0100
To: "Anselm Hannemann Web Development" <info@anselm-hannemann.com>
Cc: public-respimg@w3.org
Message-ID: <op.wctczvtpte2ec8@aimac.local>
On Sun, 15 Apr 2012 11:34:12 +0100, Anselm Hannemann Web Development  
<info@anselm-hannemann.com> wrote:

> No, not yet. That is what we now try to manage.

In that case I'd like to propose use-cases and requirements for discussion:

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  
     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:

     8. Images designed/cropped for wide screens are poor fit on portrait  
screens and vice versa.
     9. 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).


     A. No wasted bandwidth.
     B. No extra HTTP requests.
     C. No complex or overly verbose markup.
     D. Hard to get wrong (should survive mindless copy&pasting from  
w3schools' misinterpretation of the feature).
     E. 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).
     F. Needs to work with new/unusual types of networks and screens, and  
should not get in the way of browsers innovating in this area.
     G. Easy to deploy on existing infrastructure (shared hosting, CDNs).

Nice to haves:

     H. Easy to get right (non-geeks who "just want their blog to look  
nice" should be able to figure it out).
     I. 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).
     J. Allow authors to say when quality is most important.
     K. Be familiar to users of current solutions, follow existing  
practices where possible.
     L. Achieved quality isn't worse than the best UA/device can provide.

regards, Kornel Lesiński
Received on Sunday, 15 April 2012 15:51:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:07 UTC