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

On Feb 3, at 6:11 PM, Fred Andrews wrote:

> The following article might be of interest:
> http://blog.cloudfour.com/the-real-conflict-behind-picture-and-srcset/
> 
> I do not believe the proposals seeking FPWD have addressed this matter.  The srcset proposal adds a clause giving the UA a choice, but it is not clear that the UA has the information needed to make a choice.  The srcset syntax appears be just media query based 'hints'.  The syntax does not even appear to define the resolution scaling difference between the images, so it is not clear that a UA even know which is a lower or higher resolution image.  Media query hints do not define this information and could have an arbitrary relationship to the actual image resolution.

I’d note here that Jason Grigsby, the author of that post, is a member of the RICG and a direct contributor to both the Use Cases document and the `picture` extension specification.

Your objection was to the `picture` element, but you went on to describe `srcset`; I think it’s possible the two are being conflated here. `srcset` doesn’t make use of media queries at all. In the simplest case: a single resolution “toggle” on  an `img` element, that syntax would look like this:

`<img src="sd.jpg" srcset="fallback-hd.jpg 2x">`

The `2x` is both the qualifying “hint,” and the “this is a high resolution image” flag for the UA—if the client’s browsing environment qualifies for the HD option at all, the UA then determines whether it should be requested based on factors like user preference, bandwidth, and so on. If the UA determines that the high resolution image shouldn’t be requested, the image’s `src` is requested as usual.

I’m afraid I don’t fully understand your objection, which is likely my own fault. As authors, “hints” are the best we can provide for this sort of thing: “in an ideal world, request source X. If bandwidth is limited by connection or preference, don’t.” Leaving the bandwidth-throttling decision entirely in the hands of authors will lead to an inconsistent experience for users at best, and complete omission at worst. Again, these concerns are detailed in Yoav’s post better than I could hope to explain them: http://mobile.smashingmagazine.com/2013/01/09/bandwidth-media-queries-we-dont-need-em/ If I’m misinterpreting you somehow, I’d be interested in seeing a (pseudocode) example demonstrating what you mean.

In terms of how UAs gather the relevant information, that’s another matter altogether—we don’t aim to reproduce the efforts of the group(s) responsible for the Network Information API specification ( http://www.w3.org/TR/netinfo-api/ ).


Thanks,
Mat Marquis


> 
> cheers
> Fred
> 
> From: silviapfeiffer1@gmail.com
> Date: Mon, 4 Feb 2013 07:39:01 +1100
> To: fredandw@live.com
> CC: yoav@yoav.ws; mat@matmarquis.com; public-html-admin@w3.org
> Subject: Re: CfC: to publish "The picture element" specification as a First Public Working Draft (FPWD)
> 
> [- <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?
> 
> 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.
> 
> Regards,
> Silvia.