- From: Bruce Lawson <brucel@opera.com>
- Date: Tue, 15 May 2012 22:46:44 +0100
- To: "Andy Davies" <dajdavies@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: whatwg@lists.whatwg.org
On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, May 15, 2012 at 1:42 PM, Andy Davies <dajdavies@gmail.com> wrote: >> Looking at the srcset proposal it appears to be recreating aspects of >> media-queries in a terse less obvious form... >> >> <img src="face-600-200 at 1.jpeg" alt="" >> srcset="face-600-200 at 1.jpeg 600w 200h 1x, >> face-600-200 at 2.jpeg 600w 200h 2x, >> face-icon.png 200w 200h"> >> >> We've already got media queries so surelt we should be using them to >> determine which image should be used and if media-queries don't have >> features we need then we should be extending them... >> >> I'd like to see media-queries extended to support bandwidth, svg etc., >> then we give developers the option to detected features and choose >> media types appropriately. > > The "600w 200h" bit can be directly translated into a media query - > it's equivalent to "(max-width: 600px) and (max-height: 200px)". It's > collapsed into a custom syntax for terseness. Just so I understand 1) the 600w 200h bit replicates the functionality of the familiar Media Queries syntax but in a new unfamiliar microsyntax which many have argued is ugly, unintuitive and prone to error (http://www.w3.org/community/respimg/2012/05/11/respimg-proposal) 2) The new bit is the descriptors of pixel density (1x 2x etc). This isn't "media queried" because the precise mechanism by which one image is chosen over the other is left to the UA to decide based upon heuristics. Those heuristics may be secret sauces that give a browser a competitive advantage over another; they may be based on data the browser has accumulated over time (On my current "Bruce's bedroom WiFi" I know I have medium network speed but very low latency so I will tend to favour images with characteristic X) and so which aren't available to query with MQs because MQs are stateless; they may be based upon certain characteristics that could conceivably be available to MQs in the future (Do I support JS? Am I touch enabled?) but aren't yet. Is that accurate? I'm sympathetic to (2); why require a developer to think of and describe every permutation if the environment, when she could instead describe that which she knows - the images - and then allow the UA to take the decision. As time goes on, UAs get cleverer, so behaviour improves without the markup needing changing. But it doesn't seem necessary to saddle authors with (1) to acheive (2), as far as I can see. bruce-speaking-for-myself-not-Opera
Received on Tuesday, 15 May 2012 21:47:27 UTC