W3C home > Mailing lists > Public > public-respimg@w3.org > February 2013

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

From: Fred Andrews <fredandw@live.com>
Date: Sat, 2 Feb 2013 23:39:53 +0000
Message-ID: <BLU002-W192BEB9B4C76C816F70AB55AA030@phx.gbl>
To: "public-html-admin@w3.org" <public-html-admin@w3.org>
CC: "public-respimg@w3.org" <public-respimg@w3.org>, PUA CG <public-pua@w3.org>
I object to this being publish as a FPWD.

The design of the picture element and srcset both fail to address the most fundamental use case which is giving the UA a choice in the selection of the image resolution to use.  This choice is needed to meet two critical use cases: 1. allowing lower resolution images to be chosen when the UA considers them adequate and to reduce load time and bandwidth usage; 2. allowing higher resolution images to be chosen when the UA considers them needed to give sharp presentation on high DPI screens or when otherwise required based on image box size or transforms or when content is magnified.

Both proposals fail to meet these fundamental needs.  Both proposals dictate the resource choice based on media query parameters which have a weak relationship to the actual needed resource.  Further, dictating the choice gives the UA no choice in the decision and no room to innovate.  For example a UA can not confidently decide to use lower resolution images to save bandwidth and reduce page load time or to offer the user a 'click to sharpen' action on images which downloads a higher resolution image.  For example, a UA can not choose to downscale a locally cached high resolution image rather than downloading a lower resolution image.

Other proposals have been discussed in length on the whatwg mailing list and Ian Hickson has failed to integrate the suggestions or meet these fundamental use cases.  Other people have pointed out the unnecessary complexity for web content developers in trying to used these proposals which I believe is caused by conflating the image resolution choice with media query art-direction choices etc and the inherent weak relationship between the media query parameters and the required image resolution.

A redesign needs to start by separating the image resolution choice from and 'media query' parameters.  This resolution choice is fundamentally orthogonal to the 'art direction' etc use cases.  This choice can not be based on a media query of the screen DPI or viewport size as this has a weak relationship to the needed image resolution, and the choice can not be dictated in the standard as this gives the UA no choice.  If the UA is to have choice then the set of images must be simple scaled versions of the same image. There are lots of other more minor issues to be worked through by they should be easier to reach consensus on.  A media query based selection proposal could work orthogonally for the art-direction use cases etc.

Solutions to these use cases are needed urgently and this process has dragged on far too long.   A review of the process may be in order.

In the vacuum created by the failure to meet these use cases other proposals to address the matter on the server-side are emerging, such as the Client-Hints proposal.  Addressing the issue on the server-size requires the UA to unnecessarily share a lot of state and this is a privacy concern.   As Chair the PUA CG this 'required' leaking of UA state is a great concern and I would like the HTML support for image adaptation to be solved on the client side so that the server-side solutions can take advantage of it and transition to using client-side image choice.



Received on Saturday, 2 February 2013 23:40:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:08 UTC