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

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

From: Fred Andrews <fredandw@live.com>
Date: Tue, 5 Feb 2013 02:06:32 +0000
Message-ID: <BLU002-W16763894F0AE825C11C75B0AA000@phx.gbl>
To: "Paul.Cotton@microsoft.com" <paul.cotton@microsoft.com>
CC: "public-html-admin@w3.org" <public-html-admin@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>




I object to the "The srcset attribute" specification being
published as a FPWD on the basis that the design makes no attempt
to meet many of use cases and requirements of the 'Use Cases and
Requirements for Standardizing Responsive Images' and that the
editors refuse to consider design changes that would meet these
use cases.  Further, the srcset specification is related to "The
picture element" specification and the two can not be considered
in isolation.

I would note that the srcset 'author hints' are based on media
features, just as are media-queries, but with a different and
limited syntax.  There is a slight difference as the resolution
can be UA defined, but it would be expected to be related to the
device resolution and the language in the specification reflects
this.  The media queries support in the picture element
specification handles all the use cases that the 'author hints'
in the srcset specification handle and more.  The only
significant difference is that the proponents have inserted a
clause allowing the UA to choose an image, however they have
failed and refuse to back up this choice but supplying the UA
with the information needed to make all but a limited choice
based on the author supplied hints.


* Use cases and requirements
http://usecases.responsiveimages.org/

The design of the srcset specification fails to address many use
cases and requirements articulated in the 'Use Cases and
Requirements for Standardizing Responsive Images':
http://usecases.responsiveimages.org/

"1 Introduction

...

On the one hand, the `srcset` attribute allows authors to define
various image resources and “hints” that assist a user agent to
determine the most appropriate image source to display. Given a
set of image resources, the user agent has the option of either
following or overriding the author’s declarations to optimize the
user experience based on criteria such as display density,
connection type, user preferences, and so on."

The espoused goal of allowing the user agent to have the option
to override the authors declarations is not supported in the
srcset specification design.  The specification does not even
communicate the image sizes or even the relationship between the
images sizes - the only information supplied is a set of files
and the authors hints and if the UA is to ignore the authors
hints then it is left with just a list of files and could do no
better than making a random choice.


"3.5 Relative units

A common practice in creating flexible layouts is to specify the
size values in media queries as relative units: em, rem, vw/vh
etc. See, for example, Lyza Gardner's article The EMs have it:
Proportional Media Queries FTW! . This approach commonly uses ems
in order to reflow layouts based on users’ zoom preferences, or
to resize elements through JavaScript by dynamically altering a
font-size value.

In flexible layout designs, when a user zooms into a design,
proportionally scaled images can be blurry or pixelated,
affecting the image's impact and function (for example, on
televisions or when projecting). So swapping to a more suitable
image is used to overcome this problem."


This section mentions use cases that occur post-layout and in
order for the UA to solved technical challenges such as choosing
a sharp image it needs to know the images sizes.  To choose the
lowest or highest resolution images the UA would need to know the
relationship between them.  The srcset design specification fails
to supply this information to the UA.


"3.8 User control over sources

In situations where the user knows their bandwidth is limited or
expensive (e.g., while roaming), the browser could assist users
by:

 * giving users an option to only download images in the quality
   they desire - or disable images all together, as Google Chrome
   currently does through site preferences.
 
 * automatically select the most suitable image for the browsing
   environment.

There are browsers already catering for these kinds of
situations: for example Opera Mini provides users with a choice
of image quality (but those images are compressed on the
server). Amazon's Silk browser also compresses images 'in the
cloud' (i.e., through their own proxy servers) before serving
those images to a user's device."

The srcset specification gives the UA no information about the
'quality' of each image and thus could not support these use
cases.


"4 Requirements

The use cases give rise to the following requirements:

 1. The solution MUST afford developers the ability to match
   image sources with particular media features and/or media
   types - and have the user agent update the source of an image
   as the media features and media types of the browser
   environment change dynamically."

I would note that this requirment includes making changes to the
images post-layout.  The srcset hints are designed for pre-layout
selection when the actual required images size is unknown.  Once
the layout is computed the UA could better use information about
the actual image sizes to select an appropriate images but the
srcset design fails to support this information.


" 5. The solution MUST provide developers with a means to
   programmatically interface with image resources, as well as
   access relevant attributes and methods that make the solution
   practical to work with (i.e., it shouldn't require complicated
   Regex or nested loops to manipulate values). In addition, the
   solution MUST provide means to hook into relevant events
   resulting from changes in state (unavailable, partially
   available, completely available, broken). In any case, an API
   SHOULD provide a means to:

     ...

     * Determine what environmental condition caused the current
       source to be selected (reflected as, for example, a CSS
       Media Query)."

If the UA is to have a choice to select an image then it will
not be possible to 'Determine what environmental condition caused
the current source to be selected'.  This might be addressed by
returning a generic 'UA Chosen' response.

 "10. The solution SHOULD afford user agents with the ability to
 provide a user-settable preference for controlling which source
 of an image they prefer. For example, preference options could
 include: 'always lowest resolution', 'always high
 resolution', 'download high resolution as bandwidth permits',
 and so on. To be clear, user agents are not required to provide
 such a user-settable preference, but the solution needs to be
 designed in such a way that it could be done."

The srcset specification design does not communicate any
qualities about the images such as their resolution or size and
thus the UA does not have the information needed to meet this
requirement.



* Srcset specification
http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/

The srcset proposal is inconsistent with the design goals for the
srcset and picture specifications of using the picture element
for art-direction and the srcset for only resolution
choice. There is no mention in the srcset specification that the
author must only use it to supply the same image at different
resolutions. On the contrary the specification warns the UA not
to select images not specified by the author.

Much of the language and examples support the art-direction use
case which conflicts with the goal of using srcset for only a
resolution choice of the same image.


"4 Additions to the img element

...

The attribute essentially takes a comma-separated list of URLs
each with one or more descriptors giving the maximum viewport
dimensions and pixel density allowed to use the image. From the
available options, the user agent then picks the most appropriate
image. If the viewport dimensions or pixel density changes, the
user agent can replace the image data with a new image on the
fly."

I would note that the specification mentions post-layout changes
to the selected images.  After layout the UA can better use the
image sizes to select a suitable image but the design does not
supply this information and the editors refuse to consider
supplying this information.

"To specify an image, give first a URL, then one or more
descriptors of the form 100w, 100h, or 2x, where '100w' means
'maximum viewport width of 100 CSS pixels', '100h' is the same
but for height, and '2x' means 'maximum pixel density of 2 device
pixels per CSS pixel'."

I would note that the language is in terms of media features, the
viewport size and the device resolution.  This is a subset of the
media-query handling of the 'picture' element specification.


"5 Image candidate strings
...

In this example, a banner that takes half the viewport is
provided in two versions, one for wide screen and one for narrow
screens.

<h1><img alt='The Breakfast Combo'
         src='banner.jpeg'
         srcset='banner-HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x'></h1>"

This example is clearly an 'art-direction' use, and not just an
image resolution choice.  This is inconsistent with the design
separation between the srcset specification and the picture
element specification.


"7 Processing the image candidates

...

  17. Optionally, return the URL of an entry in candidates chosen
by the user agent, and that entry's associated pixel density, and
then abort these steps. The user agent may apply any algorithm or
heuristic in its selection of an entry for the purposes of this
step.

This allows a user agent to override the default algorithm (as
described in subsequent steps) in case the user agent has a
reason to do so. For example, it would allow the user agent in
highly bandwidth-constrained conditions to intentionally opt to
use an image intended for a smaller screen size, on the
assumption that it'll probably be good enough. Implementors are
urged to avoid doing this if at all possible, to let authors have
predictable results. The results of using an image intended for a
different viewport size can be, at a minimum, aesthetically
displeasing.

This clause is not necessary to select images that are of lower
pixel density than the display can handle, because the definition
of pixel density below is also left up to the user agent. This
step is only needed to allow user agents to pick images intended
for viewports with other dimensions."

The only supported information for making a choice is the author
supplied hints.  The range of choices supported is minimal, and
if the UA wishes to ignore the author hints to make its own
choice then it has no information to work with.  I do not believe
this gives the UA any real choice.  For example the user agent
can not choose an image that gives sharp presentation because it
does not know their size, and it can not choose the smallest, or
the largest.  If you discount the 'choice' added in this clause
then the srcset specification is subsumed by the 'picture'
specification.

Further, the wording does not make it clear that the choices MUST
be simple scaled versions of the same image, and appears to
advise the UA that the author can supply completely different images
which is an art-direction use case and should not be part of the
srcset design.


"8 Adaptive images

...


Consider a situation where on wide screens (wider than 600 CSS
pixels) a 300×150 image named a-rectangle.png is to be used, but
on smaller screens (600 CSS pixels and less), a smaller 100×100
image called a-square.png is to be used. The markup for this
would look like this:

<figure>
 <img src='a-rectangle.png' srcset='a-square.png 600w'
      alt='Barney Frank wears a suit and glasses.'>
 <figcaption>Barney Frank, 2011</figcaption>
</figure>"

This example is clearly an art-direction use case and not just a
choice between the same image at different resolutions.

cheers
Fred
Received on Tuesday, 5 February 2013 02:07:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2013 02:07:02 GMT