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

Wed Nov 13 10:31:01 PST 2013

On Tue, Nov 12, 2013 at 12:50 PM, 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>
>

Based on the above, the "Feature" image of say an article or recipe would
be added as a background image?
>From an Authors point of view.. yikes that's ugly, but more importantly
could be a large maintenance nightmare.

Real world use case #1:
- I have a large scale corporate website that serves Articles and Recipes
through the same template(s), including the <head>.
- In order to have an Article and Recipe "feature image" responsive with
this solution I would need to now put this in the <head>:

<style type="text/css">
@media (min-width: 480px) {
  .artdirected-article {
    width: 30px;
    height: 30px;
    background-image: image-set(url(article-small.png) 1x,
url(article-small-hires.png) 2x);
    }
.artdirected-recipe {
    width: 30px;
    height: 30px;
    background-image: image-set(url(recipe-small.png) 1x,
url(recipe-small-hires.png) 2x);
    }
}
@media (min-width: 600px) {
  .artdirected-article {
    width: 60px;
    height: 60px;
    background-image: image-set(url(article-large.png) 1x,
url(article-large-hires.png) 2x);
    }
.artdirected-recipe {
    width: 60px;
    height: 60px;
    background-image: image-set(url(recipe-large.png) 1x,
url(recipe-large-hires.png) 2x);
    }
}
</style>

Then, modify templates in order to render these separately:
<div class="artdirected-article"></div>
<div class="artdirected-recipe"></div>

Now what if my templates are also used for TV Show details, Host details...
- Add 2 more entries into the <head>
- abstract the templates for more logic and/or just create separate
templates (which seems as though it may be easier to now do that, yikes)

It also seems as though we'd be adding a boatload of code to the head that
may or may not even be used, so now I would need new MasterPages to render
different <head>'s for different templates.... you get where I'm going with
this?

>
> 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.
>

Real world use case #2 (based on "Compatibility is solid"):

Based on the Content from Use Case #1 (Articles and Recipes):
- There is an overall corporate requirement to have Article and Recipe
"Feature" images print along with the Content (Directions, Ingredients
etc.) when a user prints the page. (The Recipes community is notoriously
adept at printing)
- UA's are notoriously horrible at printing css background images.
- I have a choice to make now as an Author -- Do not make Feature images
responsive (based on this solution) or add in more work-a-rounds to have an
image available for printing.

> Adam
>

I applaud the effort to try and utilize existing infrastructure with this
but use case #2 (printing) makes it a show stopper for me.

Cheers,
D.