Re: A Unified solution to <picture>

Without comment on the technical merit of the proposal or the underlying use case:

You might want to consider vetting this use case itself—independent of the solution you’re proposing—either here or on the WHATWG mailing list, as we did with the use cases we’ve already established in usecases.responsiveimages.org. You’ve just posted this proposed solution to three mailing lists, the GitHub issue tracker for `picture`, and the W3C bug tracker without any discussion of the viability of the use case it aims to solve in the first place.

While I appreciate that you have strong feelings on the subject, your best bet is to establish consensus that there’s a need for this solution in the first place. We’ve already expressed that this isn’t a use case the RICG is currently willing to undertake as part of our current proposal, as no one involved in discussions thus far has expressed a need for context-aware image source selection based on the size of the `picture` element. I don’t expect you to take my word for it entirely, but that fact may be worth considering at the outset.

-M


On Wednesday, Feb 27, 2013, at 6:24 AM, Nathanael D. Jones wrote:

> A Unified solution to <picture>
> 
> Perhaps there's a very simple way to support both pre- and post-layout queries with <picture>, and sacrifice neither functionality or performance.
> 
> If sources specify the dimensions of the images (and more than one image matches the media queries), we delay image fetching until CSS is downloaded; otherwise fetching can occur immediately.
> 
> We can then apply sizing constraints to further filter the list of images (media queries are still king, but if more than 1 image 'matches', we use size constraints).
> 
> I've written up the details here: https://gist.github.com/nathanaeljones/5047077
> 
> --- 
> 
> I also propose the expansion of the Use Cases and Requirements document to include: 
> 
> 11 The solution SHOULD offer an method to leverage breakpoints defined in CSS.
> 
> 12. The solution SHOULD support a simplified syntax to support primary use case 3.1 (preferably a list of images and their dimensions), in order to reach users of content management systems and those without detailed knowledge of CSS media queries.
> 
> This allows complexity to be moved from HTML to CSS, and removes the need for high-volume repetition of breakpoint logic.
> 
> Authors who wish to use responsive web design will be able to use a CSS framework or snippet and matching CSS classes on <picture> to achieve responsive images - a path much less intimidating than CSS media queries, and much easier for CMSes and authoring tools to support (how would a GUI for media queries be designed)?
> 
> I fear for adoption of <picture> unless we can make it CMS and 'non-coder' friendly. 
> 
> Thanks,
> Nathanael
> 
> 
> On Wed, Feb 6, 2013 at 7:31 PM, Edward O'Connor <eoconnor@apple.com> wrote:
> Hi Fred,
> 
> You wrote:
> 
> > If the 'picture' and 'srcset' proposals are limited to[…] using only
> > information available pre-layout[…] it may not be proper for ambiguity
> > in the RICG proposals to delay other development work in an area that
> > needs urgent attention.
> 
> I'd like to clarify two things:
> 
> 1) The srcset="" specification is not a proposal of the Responsive
>    Images Community Group, although feedback from the members of that
>    group have certainly contributed to the feature's design.
> 
> 2) By working on the srcset="" nor <picture> specifications within this
>    working group, those working on them are not delaying other work that
>    you or other WG members may want to take on. In particular, if you
>    would like to work on a proposal for an adaptive images feature that
>    relies on layout information, please do so! I would be happy to
>    review a draft in that area.
> 
> > It is not immediately obvious to me how the specialized 'picture' and
> > 'srcset' solutions proposed by the RICG could fit alongside more
> > general solutions and it is likely that more general solution would
> > subsume the current proposals.
> 
> I think we can address such confusion within these drafts when and if a
> more general solution is produced.
> 
> 
> Thanks,
> Ted
> 
>