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

Re: The Hard Part

From: <steve@steveclaflin.com>
Date: Tue, 10 Feb 2015 14:09:39 -0600
To: Eric Portis <lists@ericportis.com>
Cc: public-respimg@w3.org
Message-ID: <bd9f7ec7b0a0e227af3b0a7d6f5711f2@steveclaflin.com>
On 2015-02-09 14:31, Eric Portis wrote:

> A bit of “view source” shows a boatload of picturefill, a
> smattering of picture, mostly x descriptors, and nary a w descriptor
> in sight. The [8] numbers [9] indicate [10] that this is a
> representative sample; it seems that the Hi-DPI and art direction use
> cases are easier for folks to wrap their minds around than
> resolution-switching. Which brings us to:
> 

Good to see that subsequent tweets do show the use of w!

Ever since my first exposure to this group, I've been asking myself the 
question "Why the emphasis on x instead of w?"

Unless I've missed a page somewhere, the use cases I've seen are 
somewhat generic - they list a set of categories a developer choice 
might fall into, but not an actual task-at-hand (I'm looking at 
http://usecases.responsiveimages.org/#resolution-based-selection).

For example, I can think of a specific image situation where the x 
descriptor is better than w: images that don't get resized via CSS 
(specifically that they wouldn't be given a CSS width in percent, or 
aren't constrained by max-width in a container with a percentage width). 
  This would include things like buttons or inline icons that one would 
expect to scale with the font size.

If I have a big company logo that is supposed to go across the entire 
top of the page (or across the full width of a floating div, or an image 
using half of a div's width, etc.), I don't see how an x descriptor 
alone would be useful.  w could be, and w combined with x would 
certainly be useful.

So, I think there should be more emphasis on w descriptors, both in 
pages using responsive images and in browser development of the 
responsive images feature set.

Also, along the lines of what someone else has suggested, I would 
propose that the flowchart be broken up into several separate charts 
based on more specific use cases.
Received on Tuesday, 10 February 2015 20:00:13 UTC

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