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

Thank you, this echos many of the points I have raised.

The decision to consider only pre-layout information, the media query features, in the choice of the images does seem to be the blocker.  Some people insist that the solution space be limited in this way, and thus reject alternatives that take advantage of other information or even more general solutions that would also handle their requirements.

There is an important matter of scope involved here.  If the 'picture' 
and 'srcset' proposals are limited to use using only information 
available pre-layout, that is media query features, then it may not be 
proper for the RICG to claim any authority over more general responsive 
image develop and it may not be proper for ambiguity in the RICG 
proposals to delay other development work in an area that needs urgent 
attention.  I suggest that it should be a requirement for acceptance of 
the proposals for publication as FPWD that the scope be well defined.  
This is not a technical matter that can be addressed in bugs filed 
against the proposals.

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.

Btw: You might also be interested in the following discussion on the RICG and WHATWG mailing lists:
http://lists.w3.org/Archives/Public/public-respimg/2012Nov/0001.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037772.html

I have run some quick traces of website resource loading with a proxy adding significant latency and limiting bandwidth to simulate a mobile device.  A typical result using Google Chrome to load youtube.com: after the html resource is loaded the browser initiates the loading of style sheets and Javascript resources and blocks until the Javascript files are loaded before loading any images.  The style sheets are completely loaded before these Javascript resources and thus well before any images are loaded.  Firefox is similar but initiates the loading of a few images along with the style sheets and Javascript.  I did not fined any websites for which all the images are requested at the same time as the style sheets - in part because the style sheets define many images.  I did find websites that do not have this dependency on Javascript resources and for which delaying image loads until after loading the style sheets would add some latency.

cheers
Fred

From: nathanael.jones@gmail.com
Date: Tue, 5 Feb 2013 21:36:25 +0100
To: mat@matmarquis.com
CC: fredandw@live.com; paul.cotton@microsoft.com; public-html-admin@w3.org; public-respimg@w3.org
Subject: Re: CfC: to publish "The srcset attribute" specification as a First  Public Working Draft (FPWD)

I think many people were expecting a solution based on element size. 


While that may not be a use-case you've aimed to solve, I think it should be the *primary* use-case, as it provides a simple solution to nearly every other use-case documented. 


Here's my full proposal:
https://gist.github.com/nathanaeljones/4706093

For the record: 


I do not believe the advantages of slightly-earlier prefetching outweigh the benefits of a CSS-based approach. There are many possible optimizations available to ensure the delay can be reduced to ~40ms for a cache miss (Probably ~15ms with SPDY), and it is simply not worth the markup complexity required. 


Best regards,Nathanael Jones




On Tue, Feb 5, 2013 at 1:46 PM, Mathew Marquis <mat@matmarquis.com> wrote:


On Tuesday, Feb 5, 2013, at 12:30 AM, Fred Andrews wrote:





Perhaps the problem needs to defined in even simpler terms.

Given the input string "image_200x100.jpg 1x, image_400x200.jpg 2x"
and a target image box size of 20x10 or 60x30 or 100x50 or


200x100 or 300x150 or 400x200 or 800x400 or 1920x960 device
pixels please supply a computation that selects the smallest
image that gives a sharp presentation?

The answers:
20x10: image_200x100.jpg
60x20: image_200x100.jpg


100x50: image_200x100.jpg
200x100: image_200x100.jpg
300x150: image_400x200.jpg
400x200: image_400x200.jpg
800x400: image_400x200.jpg
1920x960: image_400x200.jpg

Another example: given the input string "image_300x150.jpg 1x,


image_600x300.jpg 2x" and the same target image box sizes?

Wait, so you’re talking about *contextually-aware* image selection based on the size of the containing element? I guess this is the root of the confusion—this isn’t a use case we’ve aimed to solve, and there hasn’t been call for it. Unfortunately, this use case would also be impossible to accommodate: the UA doesn’t have information about the layout available at the time the images are [pre]fetched.


Any flags on either element dealing with sizing or resolution are in reference to the client’s *display*, similar to (or using) media queries. Choosing the image source size most appropriate for a container always 50% of the available screen will require consideration on the part of the author, as they must do currently with layout elements and CSS media query breakpoints.


I apologize for the confusion.


[ snip ]