[whatwg] <picture> / <img srcset> not needed

[D. Pitchford]

On 2012-05-16, at 6:44 PM, Aldrik Dunbar wrote:

>> It's still verbose even if you shift the verbosity into a separate
>> file; the shifting only matters if you're going to be reusing the
>> image many times.  I'm not certain that's the case here - if the same
>> image is being used over and over again, it's probably a decorative
>> image, not a content image, and so belongs in CSS.
> 
> I hadn't thought much about the reuse case which is a plus. For example 
> image hosters could provide a single url which could seamlessly be 
> embedded on forums and blogs, linked to on twitter, etc and all without 
> the users ever having to worry about image size/dpi.
> 
>>>> and doesn't do any kind of negotiation resolution.
>>> I'm sorry, not sure what you mean.
>> 
>> It's what the "Nx" component of the @srcset syntax is for - you can
>> tell the browser about multiple resolutions of the same image, and the
>> browser decides which one to request.  (See my blog post at
>> <http://www.xanthir.com/blog/b4Hv0> for why this sort of thing is more
>> difficult than you might think.)
> 
> Yep, Odin also kindly pointed me towards your blog.
> 
> I don't really see how srcset makes implementing a "low 
> bandwidth/resolution mode" much easier. Such a mode would lower the CSS 
> resolution and the appropriate file gets requested. This could be done 
> selectively for each SVG, starting at default dpi and upon a request of 
> a non cached resource while in low-mode quit and reprocess the media 
> queries with the lower resolution.
> 
> Of course if someone comes up with a progressively loaded image format 
> this could be handled much more elegantly.

Someone has a proof of concept yes:
http://blog.yoav.ws/2012/05/Responsive-image-format

Very interesting, would really need to be ripped apart though to see if it would work. At the very least could possibly leverage the theory put forth, implementation could be different.
'picuture' and 'imgscr' not needed.

D.