Re: CfC: to publish "The picture element" specification as a First Public Working Draft (FPWD)

On Feb 3, at 3:39 PM, Silvia Pfeiffer wrote:

> [- <public-respimg@w3.org>, <public-pua@w3.org> ; posting to multiple lists fragments email threads and is frowned upon]
> 
> On Mon, Feb 4, 2013 at 12:45 AM, Fred Andrews <fredandw@live.com> wrote:
> 
> Section 8 'Adaptive images' of the srcset proposal appears inconsistent with the intent of the proposal.  There are examples using the srcset as a viewport media query to select between images.  Perhaps just remove this section.
>  
> I agree that this section should be modified to accommodate the use of `srcset` with `<picture>`.
> 
> 
> What I am hearing from the discussions is that the 'srcset' and the <picture> proposal are not alternatives but work best in combination. Is this correct?

Absolutely. We attempted to clarify the relationship between the two in the `picture` extension specification: http://picture.responsiveimages.org/#relationship-to-srcset

The two syntaxes do share some overlap where `srcset` was later retrofitted with `w` and `h` options, as outlined in Section 8 of the `srcset` document. This syntax is strictly pixel-based, and limited in use as the equivalent of `max-width/height` media queries. For example: this extension to the syntax would require authors seeking image breakpoint parity with a layout specced using em-based `min-width` media queries—a common development practice—to do a great deal of calculation and manual conversion. Perhaps as a result, the `picture` syntax is overwhelmingly preferred by authors for this purpose: http://www.w3.org/community/respimg/2012/05/11/respimg-proposal/

Also, were this overlapping syntax removed from the `srcset` extension specification the markup pattern would very closely match CSS’ `image-set` function ( http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html ), and I think there’s real value to maintaining that sort of cross-concern parity: media queries for “size” heuristics, and `srcset`/`image-set` for resolution heuristics.

> If so, I would suggest the authors of both specifications to get together and write a single extension specification that includes the motivation for responsive image design, explains both approaches, their specifications, and examples on when to use what. As a Web author and browser developer I'd much prefer dealing with a single document for responsive images than two or now even three.
> 
> If this is not possible, I'd like to know the reasons. Thanks.

While they do serve to address a number of use cases in combination, the markup patterns can be used independent of one another—`srcset` for simple resolution switching on an `img` tag, or a `picture` element with `source` elements using `src` strictly to determine the appropriate image source for the “art direction” use case. I don’t feel it’s entirely inappropriate for the documents to remain separate where they can function independent of one another, but I’m certainly not opposed to the idea.

Merging the two specifications has been one of the the RICG’s goals for some time now. I’d be very happy to work towards those ends, though I would propose that the scope of the `srcset` attribute be reduced to a set of resolution heuristics as a part of that effort. I want to stress that this does represent the consensus of the Community Group, rather than simply my own opinions on the matter.

I do know that maintaining parity with the `srcset` as specced by the WHATWG is likely a concern, but I’d be more than happy to discuss merging the extension specifications further if the editor of the `srcset` doc is amenable to the idea. A native solution to the laundry-list of “responsive images” concerns is long overdue, but I’m confident that the end is in sight.

Thanks,
Mat Marquis