Re: [whatwg] <img srcset> for responsive bitmapped content images

You should look into the previous discussions at
http://www.w3.org/community/respimg/

There's also a prototype using media queries at
https://github.com/scottjehl/picturefill. I realize you specifically said
you think media queries don't solve all of the problems, but it seems worth
looking at.


On Thu, May 10, 2012 at 3:58 AM, Edward O'Connor <eoconnor@apple.com> wrote:

> Hi,
>
> When authors adapt their sites for high-resolution displays such as the
> iPhone's Retina display, they often need to be able to use different
> assets representing the same image. Doing this for content images in
> HTML is currently much more of a pain than it is in CSS (and it can be a
> pain in CSS). I think we can best address this problem for bitmap[1]
> content image by the addition of a srcset="" attribute to the existing
> <img> element.
>
> The srcset="" attribute takes as its argument a simplified variant of
> the image-set() microsyntax[2]. It would look something like this:
>
> <img src="foo-lores.jpg"
>     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
>     alt="decent alt text for foo.">
>
> <img srcset> takes one or more comma separated image specifiers. An
> image specifier consists of a URL to an image asset and an associated
> scale factor, expressed as a number followed by the literal character
> 'x'. (The value of <img src> is treated as if it had a 1x scale
> specified, so you can avoid duplicate references to the base asset.)
>
> User Agents may make their asset selection before fetching any of the
> assets, thus avoiding multiple asset loads & the associated performance
> problems in constrained bandwidth environments.
>
> The intrinsic size of the <img> can be computed by dividing the
> intrinsic size of the actual image asset chosen with that asset's
> associated scale factor. Suppose that foo-lowres.jpg is 100x100 and
> foo-highres.jpg is 200x200 in the above example. If the UA chooses
> foo-lowres.jpg, it computes the intrisnic size as (100/1)x(100/1) =
> 100x100. If the UA chooses foo-highres.jpg, it computes the intrisnic
> size as (200/2)x(200/2) = 100x100.
>
> A nice thing about this proposal is its backwards compatibility story.
> Browsers which don't yet support <img srcset> will simply use the asset
> referenced by <img src>. A polyfill could easily be written to check for
> <img srcset> & swap out a different asset into <img src>, much like
> existing libraries which check for data-fullsrc="" or the like.
>
> Why provide a scale factor and not a media query? Well, media queries
> are claims about UA state, whereas here we're asserting something about
> the relationship between the image assets. Also, User Agents should be
> free to use whichever asset they deem best suited to their current
> situation, taking into account not just "media-queriable things" like
> device resolution but also any scaling applied to the <img> with CSS,
> its width="" and height="" attributes, or even things like the current
> page zoom level.
>
> Of course there are other things like bandwidth availability, data plan
> usage, etc. that web developers might want to take into account when
> choosing which image assets to load. This is definitely something worth
> exploring. In the future we could extend the asset descriptors to cover
> such cases. Something like this, maybe:
>
>  <img srcset="foo-lowres.jpg 1x low-bandwidth,
>              foo-highres.jpg 2x high-bandwidth">
>
> I'm purposefully not making a proposal for how to describe bandwidth,
> data plan usage, or such things here. Ultimately I don't think
> addressing the multiple-resolution case needs to wait for a solution to
> these other cases. We don't need to "SOLVE ALL THE PROBLEMS!" right now.
>
> One downside to this proposal is that the srcset="" attribute takes a
> microsyntax, and as a rule we try to avoid novel microsyntaxes in
> attribute values. I think this particular microsyntax is pretty
> straightforward and shouldn't cause all that much confusion for authors.
>
> I think this is preferable to adding a suite of attributes with complex
> inter-relationships, such as in Anselm Hannemann's proposal from last
> August[3]. In such a proposal, we would either need to have a pre-
> approved list of image scales (like Anselm's xs, s, m, l, xl), which
> over-constrains designers' ability to create, or we would be introducing
> user data into attribute names which—with the one exception of the
> data-*="" attributes—is something I really don't think we should do.
>
> Some have argued that we should "just use conneg" to serve the best
> image. This isn't an acceptable solution for at least three reasons:
>
> * The server doesn't have all of the relevant information needed to
>  pick the best image, and sending that information with every image
>  asset request is bandwidth-intensive and enables increased user
>  fingerprinting.
>
> * HTML is used in a lot of contexts, such as in EPUB, in which there's
>  no server to negotiate with in the first place.[4]
>
> * The UA should be able to "swap out" one asset for another
>  transparently after the page has loaded. For instance, the UA might
>  want to swap things out when the user zooms in.
>
> I also think this approach is better than minting a new image element,
> but I'll make that argument in another email.
>
>
> Ted
>
> 1. "What responsive image problem? Just use SVG!" :)
>
> 2. I've proposed image-set() for CSS4 Images. Here's the relevant post
>   to www-style:
>     http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
>   An implementation of image-set() has recently landed in WebKit.
>
> 3.
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-August/032977.html
>
> 4. http://lists.w3.org/Archives/Public/public-html/2011May/0401.html
>
>

Received on Thursday, 10 May 2012 12:37:19 UTC