- From: Mathew Marquis <mat@matmarquis.com>
- Date: Thu, 10 May 2012 10:45:09 -0400
- To: whatwg@whatwg.org
On May 10, 2012, at 8:36 AM, Scott González wrote: > 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. > I can’t second Scott’s suggestion enough. There is a ton of history and valuable conversation around this topic already in the Community Group, and we’ve been working with a couple of browser reps trying to get this thing solved. We’ve even gone so far as to put the solution that seems to have the most legs together as a sort-of spec, so all the details are in one easily-parsed place: https://github.com/Wilto/respimg > > 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 14:45:48 UTC