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

Tue Nov 12 11:31:05 PST 2013

On Nov 12, 2013, at 9:50 AM, Adam Barth <w3c at adambarth.com> wrote:

> On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst <derernst at 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.

Content authors can already do what is described above, and in fact often do. However, a <div> with a background-image property set is not the same as an <img> in practice. Here are a few differences:

(1) There's no ready way to have an element size automatically to its background-image (the way an <img> will to its src by default).

(2) In general, browsers will not provide the same user interaction operations for a background image as for a content image in an <img> element (e.g. ability to drag it elsewhere, context menu items to save it, etc).

(3) Assistive technologies will ignore background image holding divs for which no textual equivalent has been provided (as opposed to <img>, where they do something like reading the filename, or just indicate the presence of an image without labeling it).

(4) Software that processes content to look for images may treat content images in <img> differently from images specified as backgrounds, for instance by assuming background images are decorative and therefore less meaningful and/or less related to search terms in text on the page.

Some of the above may be addressable by using the 'content' property instead of the 'background-image' property, though using 'content' on an element as opposed to a :before or :after pseudo does not work reliably cross-browser.

Regards,
Maciej