RE: The picture element: complexity

Simon,
     srcset[x] doesn't seem to follow the same conventions as other attributes. For consistency, what if it worked the same as your mediaset attribute? For example: 
 <img mediaset="(min-width: 45em), (min-width: 18em), all"
          srcset="(large-1.jpg, med-1.jpg, small-1.jpg), (larse-2.jpg, med-2.jpg, small-2.jpg)"
          src="small-1.jpg"          alt="Accessible text">

Erik IsaksenSenior UX Engineer
3Pillar Global 

> To: public-html@w3.org; info@anselm-hannemann.com
> Date: Thu, 12 Sep 2013 15:53:27 +0200
> From: simonp@opera.com
> Subject: Re: The picture element: complexity
> 
> On Thu, 12 Sep 2013 13:50:08 +0200, Anselm Hannemann  
> <info@anselm-hannemann.com> wrote:
> 
> > Hi Simon,
> >
> > while I totally understand <picture> with its source elements is complex  
> > to implement and needs more tests than a simple attribute I wonder what  
> > you would propose as alternative to e.g. media-query usage within source  
> > elements. This is needed to solve the art direction use-case  
> > (http://usecases.responsiveimages.org/#art-direction)
> 
> Art direction based on viewport width is supported by srcset.
> 
> > amongst others (like high-contrast or print – compare:  
> > http://usecases.responsiveimages.org/#matching-media-features-and-media-types).
> 
> The example with the pie chart that wants colors on color devices but a  
> wide gray scale on non-color devices could be implemented using an SVG  
> image with media queries in CSS.
> 
> For the print case, it's not clear to me that it is a good idea to block  
> printing a page on downloading a heavy image compared to providing a link  
> to a page with heavy images (e.g. a PDF) for printing that the user can  
> navigate to and print.
> 
> > If you have an idea how this could be solved using an easier to  
> > implement syntax, I would be happy to help doing this. Simply I believe  
> > (and know for certain) the srcset attribute alone is not enough to solve  
> > the 'Responsive Images' problem entirely.
> 
> I see several options.
> 
> (1) Use only <img src> and serve a scaled down low quality high-resolution  
> image to everyone (which is the same size in bytes as a high quality  
> low-resolution image and is visually good enough on both low and high  
> resolution devices), and solve the art direction use cases with CSS  
> clipping and rotation etc.
> 
> For devices that don't have a high-resolution screen and/or have limited  
> memory, the browser can store a scaled down version of the image in  
> memory. I'm told JPEG can be decoded at half of the resolution for free  
> (https://twitter.com/pornelski/status/377770545661894656 ). It would be a  
> good idea for browsers to do that regardless of what we do for responsive  
> images to have a nicer failure mode when loading big images on  
> memory-constrained devices.
> 
> (2) Go with srcset and leave the use cases it doesn't address to SVG or  
> CSS.
> 
> (3) Redesign the picture element to encode the same information in  
> attributes on <img>.
> 
> For instance, change
> 
> <picture width="500" height="500">
>     <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg  
> 2x">
>     <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
>     <source srcset="small-1.jpg 1x, small-2.jpg 2x">
>     <img src="small-1.jpg" alt="" lazyload>
>     <p>Accessible text</p>
> </picture>
> 
> to
> 
> <img mediaset="(min-width: 45em), (min-width: 18em), all"
>       srcset1x="large-1.jpg, med-1.jpg, small-1.jpg"
>       srcset2x="larse-2.jpg, med-2.jpg, small-2.jpg"
>       src="small-1.jpg" alt="Accessible text">
> 
> where "1x" and "2x" in the attribute name can be an arbitrary number,  
> including non-integers.
> 
> -- 
> Simon Pieters
> Opera Software
>