On Tuesday, Feb 5, 2013, at 12:30 AM, Fred Andrews wrote: > > Perhaps the problem needs to defined in even simpler terms. > > Given the input string "image_200x100.jpg 1x, image_400x200.jpg 2x" > and a target image box size of 20x10 or 60x30 or 100x50 or > 200x100 or 300x150 or 400x200 or 800x400 or 1920x960 device > pixels please supply a computation that selects the smallest > image that gives a sharp presentation? > > The answers: > 20x10: image_200x100.jpg > 60x20: image_200x100.jpg > 100x50: image_200x100.jpg > 200x100: image_200x100.jpg > 300x150: image_400x200.jpg > 400x200: image_400x200.jpg > 800x400: image_400x200.jpg > 1920x960: image_400x200.jpg > > Another example: given the input string "image_300x150.jpg 1x, > image_600x300.jpg 2x" and the same target image box sizes? Wait, so you’re talking about *contextually-aware* image selection based on the size of the containing element? I guess this is the root of the confusion—this isn’t a use case we’ve aimed to solve, and there hasn’t been call for it. Unfortunately, this use case would also be impossible to accommodate: the UA doesn’t have information about the layout available at the time the images are [pre]fetched. Any flags on either element dealing with sizing or resolution are in reference to the client’s *display*, similar to (or using) media queries. Choosing the image source size most appropriate for a container always 50% of the available screen will require consideration on the part of the author, as they must do currently with layout elements and CSS media query breakpoints. I apologize for the confusion. > [ snip ]
Received on Tuesday, 5 February 2013 12:47:01 UTC