Re: A Unified solution to <picture>

In fact, many people on the mailing lists have suggested similar solutions,
and each time they were shot down over 'performance' concerns that have
since been eliminated.

Edward O'Connor stated  "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."
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0103.html

*Other than yourself, I don't know of anyone unwilling to consider
post-layout use-cases.*

Fred Andrews has strongly supported support post-layout solutions several
times:

"In any case, this does does not justify discounting use cases post-layout.
I believe this is the blocker preventing consensus and I propose
considering both."

http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0061.html
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0050.html

Jacob Mather suggested layout-based selection back in may:
http://www.w3.org/community/respimg/2012/05/16/shouldnt-we-be-defining-content-not-context/

Matt Wilcox has been pretty vocal about the need for DRY:
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/

There is no DRY solution likely to happen soon - variables in HTML are
antiethical it its nature, as incredibly awesome as they would be. Also, a
variable-based solution does not solve the fundamental problem of placing
layout decisions in HTML instead of declaring content.

Yoav Weiss confirmed my assertions regarding performance characteristics,
which was the only justification so far for blocking these use cases.
http://lists.w3.org/Archives/Public/public-respimg/2013Feb/0019.html


Also: If you take a moment to review the respimg mailing list, you'll
notice I posted there first, and was told to post in public-html, which
(according to the website) I can neither post nor subscribe to. So I
followed the instructions on the drafts and filed bugs. I was then told to
move the discussion to 'public-html-comments'. Due to various different
legal requirements, the group is split across multiple maling lists; an
issue that needs to be resolved.





On Wed, Feb 27, 2013 at 8:07 AM, Mathew Marquis <mat@matmarquis.com> wrote:

> 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.
> <https://gist.github.com/nathanaeljones/5047077#12-the-solution-should-support-a-simplified-syntax-to-support-primary-use-case-31-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>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
>>
>>
>
>