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

> Date: Mon, 4 Feb 2013 13:45:46 +0100
> From: yoav@yoav.ws

>> 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? 

The 'picture' proposal is dependent on the srcset proposal, so
I do not think they should be separated.  If anything the 'picture'
proposal should be deferred until there is consensus on the
srcset proposal.





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.

Perhaps you could elaborate on this point?

For example, why would you request images below the fold pre-layout?

So long as enough requests are pending to keep the pipeline full then
it is not immediately obvious what benefit there is queuing them all?

Perhaps part of the reason for loading the images so early is the need to
know their size to compute the layout.  If these dimensions are communicated
in the srcset then layout can proceed without downloading them and
as computers get faster the parsing latency will reduce.

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.

> 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.

There are lots of use cases post-layout.

> Therefore, including the image's resolution in the markup will not help browsers
> make a better decision regarding the optimal resource.

A lot of changes happen post-layout so this is completely wrong.  For example:
a change in the orientation; zooming; resizing of a window; a change to full
screen viewing; users optionally loading lower resolution images with the
option to download a higher resolution image, etc.

> 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).

Sorry this in unavoidable, the goal here is to give the UA information about
the images before they are loaded so that it can make a choice.  The srcset
pre-layout hints you proposal are much more complex and fragile to update
if a resource is changed.  Some development tools will be need with any
proposal to check for consistency.   I do not think this concern should dictate
limiting the uses cases to those handled pre-layout.

Anyway I gather you are not interested in considering the post-layout use
cases or supporting modes of operation that defer image choice until after
layout.  I think a proposal that took the post-layout uses cases into account
would subsume your proposal otherwise it might be possible to separate
them - I'll give it some thought.

cheers
Fred