Re: Specific use-cases

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
>

Received on Monday, 16 April 2012 10:21:34 UTC