[whatwg] Features for responsive Web design

Tue May 15 03:22:07 PDT 2012

I do not see much potential for srcset. The result of asking the
author community was overwhelmingly negative, indirection or no
indirection.

To be clear, I don't see how indirection of this level can be an
issue, under those terms anything you write in CSS to effect a HTML
element is already "indirect" - to the extent of being in a different
file entirely.

-Matt

On 15 May 2012 11:13, Matthew Wilcox <mail at matthewwilcox.com> wrote:
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakpoint:
>
> /anything/{whatever}/this/can/be/anything.jpg
>
> I've seen no objections about that aspect in the Community Group
> thread, where a number of authors have given feedback.
>
>
>
> It addresses pixel density because it uses media queries and they
> address pixel density. Any media query should be valid, so it's not
> just
>
> <meta name="case" value="large" media="min-width:900px;" />
>
> you could use
>
> <meta name="case" value="very-large" media="(device-pixel-ratio:2) and
> (min-width:30em)" />
>
> for example. MQ are by far the most flexible way of dealing with
> reacting to device constraints.
>
> What is set is the path to look for the image. This is *exactly* how
> this works in CSS already for background-images and all authors are
> familiar with this - you don't set the pixel density of an image, you
> detect the device pixel density and change the path of the image you
> send over CSS. Have a look at how almost any site is built and you'll
> see *paths* change, not *image names*. http://enochs.co.uk is one
> example.
>
>
> Requiring access to head is not much of an issue, and has not been
> raised by anyone commenting on the CG thread. Web designs tend to be
> 3-7 breakpoints that are shared site-wide. The actual design of each
> page may not be, but the breakpoints are. This is why site's with many
> types of page can all share the same list of CSS assets to load:
>
> <!-- Styling for all devices -->
> <link rel="stylesheet" media="screen" href="/assets/css/screen.core.css" />
>
> <!-- Styling for progressively larger displays -->
> <link rel="stylesheet" media="only screen and (min-width: 320px)"
> href="/assets/css/screen.320.css" />
> <link rel="stylesheet" media="only screen and (min-width: 480px)"
> href="/assets/css/screen.480.css" />
> <link rel="stylesheet" media="only screen and (min-width: 750px)"
> href="/assets/css/screen.750.css" />
> <link rel="stylesheet" media="only screen and (min-width: 960px)"
> href="/assets/css/screen.960.css" />
>
> We are proposing nothing different than that, but to set variables
> rather than to load a particular CSS file.
>
> If it works for authors using CSS, why should it not also work for
> setting image paths?
>
>
>
> -Matt
>
> On 15 May 2012 10:57, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox <mail at matthewwilcox.com> wrote:
>>> Please, have you taken a look at the latest idea?
>>>
>>> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>>
>> It was quoted and replied to in the email you just replied to.
>>
>> It has many problems. It adds a level of indirection, it imposes
>> constraints on where the resources are located and how they are named,
>> it requires access to the <head> element for adding an image in a blog
>> post, and it makes processing of URLs conditional on information
>> provided elsewhere. These are all significant issues.
>>
>> I also do not see how it addresses the pixel density use case. You
>> cannot use a media query for that because a media query queries the
>> pixel density of the device, it does not *set* the pixel density of
>> the resource.
>>
>>
>> --
>> Anne — Opera Software
>> http://annevankesteren.nl/
>> http://www.opera.com/