Am 16.05.2012 um 00:06 schrieb Chris Heilmann: > On 15/05/2012 22:46, Bruce Lawson wrote: >> On Tue, 15 May 2012 22:18:51 +0100, Tab Atkins Jr. <jackalm...@gmail.com> >> wrote: >> >>> On Tue, May 15, 2012 at 1:42 PM, Andy Davies <dajdav...@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 >> >> > I also wonder what we do with videos? Surely they have the same issues and > there is no proposal for changing the syntax there. I do not like the syntax > of this. Yes it is more terse but it smacks of the horrible syntax of > window.open properties and other comma separated visual attributes. > > From a semantic point of view this is a terrible mix of everything - > something that the picture proposal with multiple sources was not. This is what I think, too. > Let's not forget that this is a new use case - one that might get more > complex with more UA changes in the future. Maybe we have holographic images > soon with a X Y and Z position. Shoehorning this into the IMG element doesn't > make much sense to me. > > embed is the fallback to video with various sources. img is the fallback to > embed. I'd like to see picture - done like video for consistency as it is a > new use case for images. Old browsers could disregard them and new ones can > use mediaqueries to apply the different sources as needed. Yes, mediaqueries > do not all the things we need here and browsers have bugs loading various > sources instead of only one but these are things to fix in the browser > engines, not add an extra use case in the spec. And that is a reason why picture is (imo) the better option. It is far more flexible to future changes of media. I also don't think we need a now working solution but a solution that work for the next couple of years (maybe 10yrs or more). I also won't say picture is the best way to go but it is far better than the proposal that made it in some "draft" earlier this day.
-A.
