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

My concern has always been with the support for resolution
> choice by the UA which is in the srcset proposal.   I have no
> objection to the 'picture' element in isolation and it seems to
> handle the art-direction use case - the 'picture' proposal does
> include the srcset attribute on the <source> element.  Other
> significant players have objected to the verbosity of the 'picture'
> proposal (WHATWG), but it's not my concern.
>

In that case, can we move the discussion to the `srcset` CfC thread?

>
>
> My concern it how the UA can make a choice given the proposed srcset
> syntax?
> I am concerned that the srcset syntax does not define the image resolutions
> so the UA has little information to work with.  The density and viewport
> parameters in the srcset proposal are only pre-layout hints.   I believe
> the image
> sizes would be needed for the UA to choose any appropriate image to
> download
> to meet technical goals such as a rendering a sharp image with smallest
> available
> image.
>
> Perhaps there are two distinct cases:
>
> 1. Before the UA has computed the layout it can not be sure what the image
> box
> size will be and the 'hint' seems to be the proposed solution.  Sorry, the
> full
> implications of your proposal are not immediately clear to me but I am
> reviewing it.
> If you have some example choice strategies in mind then sharing them would
> be very helpful.
>
> 2. After the UA has computed the layout it knows the target box sizes of
> images
> and could use knowledge of the resolution of each available image to choose
> the smallest image to give sharp presentation.  It might also be useful to
> support
> author hints to define alternative choice strategies - for example to
> suggest the
> UA choose a lower resolution image but give the user a choice to sharpen
> etc.
> This case also handles layout changes after the page has loaded, such as an
> orientation change.
>
> Very soon, with SPDY & HTTP/2.0, it is a fair assumption that *all* the
content image requests will be sent to the server before the browser has
the page's layout.
AFAIK, even today, browsers parse out the resources destined download
before layout, and changing that post-layout is likely to be an
implementation issue, with very little short-term gain.
Therefore, including the image's resolution in the markup will not help
browsers make a better decision regarding the optimal resource. OTOH, it
will create a dependency between the HTML and external resources that will
burden maintenance (e.g. replacing an image with a larger one with
identical proportions will require an HTML change).