The patern thing is tangential. SRCSET using image dimensions instead of screen dimensions would work just as well, so would picture if it was set up to allow saying what the dimensions of each image are.
I would argue that this does address the pixel density issue though. It does it in the same way it handles em, rem, or percentage based designs: by ignoring all that stuff and just picking the image that best fits the available hardware pixels. It's more future proof too, since you "200w 200h 2x" image could also stand in as your "100w 100h 4x" image, if/when something like that comes out, without any updates needed. Art direction is solved in a simialir way: don't provide any images that look bad, and don't size the img element to a size you don't have a picture for. Using the image dimensions instead of the screen dimensions also solves the "desktop first" vs "mobile first" dilemma. Syndication becomes easier (or are your breakpoints the same as readability's?), updating the design becomes easier (no editing every image in every post because a breakpoint changed) and really simplifies use cases like the following: You're making a grid of thumbnails. At it's largest size, it's three images across. It stays this way until the images are 2/3 their size, at which point it changes to 2 columns at the original size. When the images hit half their original size, it switches to one column, full size. So one image is created at the three most likely sizes (1/1, 1/2, 1/3) and then srcset is used to make sure the -- Mike Gossmann Mathew Marquis <[email protected]> wrote: >On May 22, 2012, at 5:43 AM, Anne van Kesteren <[email protected]> wrote: > >> On Tue, May 22, 2012 at 10:21 AM, Markus Ernst <[email protected]> wrote: >>> I am somehow surprised that there are no reactions to this proposal. To me >>> as a humble author it looks like it would address the main issue of both >>> <picture> and @srcset, as it leaves the MQ to CSS, and thus separates design >>> from content. >> >> 1. It does not address the pixel density use case. 2. A pattern-based >> approach was actually mentioned in Ian Hickson's email when he >> announced the srcset attribute. >> > >We’re apt to see the element used in one of two ways: > >* Serving a size-appropriate image source in a flexible layout, wherein the >size of the images will be controlled by CSS—typically, `max-width: 100%`. >Using a pixel density MQ will serve a larger image within this constraint. >Inherent size is not a concern with this case—which is fortunate, as this will >likely require sources with varying dimensions, per the “art direction” case. > >* Serving a static-dimension asset at varying resolutions, a la Apple.com. To >always rely on the intrinsic size of another source is to negate the art >direction use case — however, we could simply add optional `width` and >`height` attributes to `picture`, constraining the higher res image to a >specified set of dimensions. This leaves control in the authors’ hands in a >simple, predictable way without negating either use case. > >I can’t speak to this personally, but Kornel has mentioned that using said >attributes instead of relying on a calculated inherent width will avoid >reflows. It should likely be an option in either case. > >> >> -- >> Anne — Opera Software >> http://annevankesteren.nl/ >> http://www.opera.com/ >
