Re: [whatwg] <imgset> responsive imgs proposition (Re: The src-N proposal)

This is possible using a set of proposals already underway, last I checked in on them: http://nicolasgallagher.com/responsive-images-using-css3/ Considering the delay involved in skipping the preparser and waiting for CSS to download (as well as the fact that the `src` *will* be prefetched, resulting in a double-request), this really leaves us in the same position as any number of script-based solutions—we’re just creating a responsive images “engine” in CSS, rather than in JavaScript or inside an SVG.

This subject has come up a number of times on the respimg list, and it always plays out largely the same way: an optimization like this would be beneficial for sure (and I’m in favor of one myself), but in this context we’re looking at creating an entire variable syntax specific to images. Obviously there’s a huge amount of implementation overhead involved in something like this, and making it a requirement in any proposal would create a *huge* barrier to implementation vs. getting a simple *extendable* markup pattern in place and building on that. Once we have a solution in place for responsive images, it makes sense that it would become a consideration in larger discussions such as http://lists.w3.org/Archives/Public/www-style/2013May/0638.html

We don’t want the search for the all-time-perfect responsive image solution to stand in the way of setting up the foundation for one, and we definitely don’t want to create a set of solutions to larger problems that can only ever apply to image sources.

-M


On Nov 12, at 12:50 PM, Adam Barth wrote:

> On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst <derernst@gmx.ch> wrote:
>> Am 12.11.2013 17:48 schrieb Markus Lanthaler:
>>> On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote:
>>>>> 
>>>>> We could define some ways to list set of images that could be
>>>> 
>>>> replaced for a given img element in HTML and then let CSS pick which
>>>> one to use for example.
>>>> 
>>>> <style type="text/css">
>>>> @media (min-width: 480px) {
>>>>    img.artdirected {
>>>>      use-src: 1;
>>>>    }
>>>> }
>>>> @media (min-width: 600px) {
>>>>    img.artdirected {
>>>>      use-src: 2;
>>>>    }
>>>> }
>>>> </style>
>>>> 
>>>> <img class="artdirected"
>>>>       src="small.jpg"
>>>>       src-1="medium.jpg"
>>>>       src-2="large.jpg"
>>>>       alt="Alternative text">
>>>> 
>>>> [...]
>>>> 
>>>> 
>>>> This may be technically incorrect or incomplete; it's just a sketch of
>>>> the idea, based on my conviction that sources belong into the <img>
>>>> element, while MQs should be kept centralised.
>>> 
>>> Using URL templates this could be simplified even further. For example by
>>> extending the meta element to allow it to set some form of global
>>> configuration variables it would be possible to define images using a
>>> simple
>>> naming convention:
>>> 
>>> <head>
>>>   <meta var="img-size" content="small">
>>>   <meta var="img-size" content="medium" media="min-width: 480px">
>>>   <meta var="img-size" content="large" media="min-width: 900px">
>>> </head>
>>> <body>
>>>   <img src="teaser-fallback.jpg" src-t="teaser-{img-size}.jpg">
>>>   <img src="profile-fallback.jpg" src-t="profile-{img-size}.jpg">
>>> </body>
>>> 
>>> If a variable is set multiple times as in the case above, the latest
>>> assignment wins. As soon as the closing head tag is encountered, the value
>>> of all variables is known and they effectively become constants that can
>>> be
>>> used to fill the URL templates of the images in the document's body.
>> 
>> That looks really cool to me. Is there any reason why this kind of approach
>> is not part of the discussion?
> 
> We might even be able to make this work without inventing anything:
> 
> <style type="text/css">
> @media (min-width: 480px) {
>  .artdirected {
>    width: 30px;
>    height: 30px;
>    background-image: image-set(url(small.png) 1x, url(small-hires.png) 2x);
> }
> }
> @media (min-width: 600px) {
>  .artdirected {
>    width: 60px;
>    height: 60px;
>    background-image: image-set(url(large.png) 1x, url(large-hires.png) 2x);
> }
> }
> </style>
> <div class="artdirected"></div>
> 
> All the information is there.  We just need to teach the preload
> scanner to parse a subset of CSS and match a subset of selectors.  If
> you stay within the "preloadable" subset, then your images will be
> loaded by the preload scanner.  Otherwise, they'll just be loaded
> normally.
> 
> What's most attractive to me about this approach is that it doesn't
> require inventing anything new, which means the compatibility story
> for older user agents is solid.  You don't need a polyfill or anything
> like that.
> 
> Adam

Received on Tuesday, 12 November 2013 18:20:08 UTC