- From: Mathew Marquis <mat@matmarquis.com>
- Date: Tue, 22 May 2012 09:42:15 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG Mailing List <whatwg@lists.whatwg.org>, Markus Ernst <derernst@gmx.ch>, Mike Gossmann <mike@c572.ca>
On May 22, 2012, at 5:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, May 22, 2012 at 10:21 AM, Markus Ernst <derernst@gmx.ch> 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/
Received on Tuesday, 22 May 2012 13:43:55 UTC