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/
