Re: Specific use-cases

As we are not actively using the mailing list, I have thrown your e-mails into a separate post:
http://www.w3.org/community/respimg/2012/04/16/summary-of-use-cases-and-requirements/

Cheers,
Anselm Hannemann

Am 16.04.2012 um 00:05 schrieb Jad:

> 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 behaviour 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?
> 
> 2012/4/15 Kornel Lesiński <kornel@geekhood.net>
>> 
>> 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 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:
>> 
>>    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).
>> 
>> 
>> 
>> 
>> Requirements:
>> 
>>    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
>>