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

[Tab Atkins Jr.]

On Tue, Nov 12, 2013 at 10:40 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth <w3c at adambarth.com> wrote:
>> 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.

Okay, here are some examples done up in as reasonable and compact a
manner as I can do, assuming certain syntaxes when they haven't yet
been created:

Use-case 1: Variable density.

src-N
<img src-1="foo.5 .5x, foo1 1x, foo2 2x, foo3 3x" src="foo1">

PreloaderCSS
<img src="foo1" id="foo">
<style>
#foo { content: replaced image-set("foo.5" .5x, "foo1" 1x, "foo2" 2x,
"foo3 3x"); }
</style>


Use-case 2: Art-direction (slightly different images based on layout
breakpoints)

src-N
<img src-1="(width < 30em) foo.5 .5x, foo1 1x, foo2 2x, foo3 3x"
     src-2="bar.5 .5x, bar1 1x, bar2 2x, bar3 3x"
     src="foo1">

PreloaderCSS
<img src="foo1" id="foo">
<style>
@media (width < 30em) { #foo { content: replaced image-set("foo.5"
.5x, "foo1" 1x, "foo2" 2x, "foo3 3x"); } }
@media (width >= 30em) { #foo { content: replaced image-set("bar.5"
.5x, "bar1" 1x, "bar2" 2x, "bar3 3x"); } }
</style>


Use-case 3: Variable-sized images

src-N
<img src-1="100% (30em) 50% (50em) 33%; foo200 200, foo400 400, foo800
800, foo1200 1200, foo1600 1600" src="foo1">

PreloaderCSS
<img src="foo1" id="foo">
<style>
#foo { content: replaced image-set("foo200" 200, "foo400" 400,
"foo800" 800, "foo1200" 1200, "foo1600" 1600); }
@media (width < 30em) { #foo { width: 100vw; }}
@media (30em <= width < 50em) { #foo { width: 50vw; }}
@media (width >= 50em) { #foo { width: 33vw; }}
</style>


These examples... do not look good.

The simplest one isn't much worse, granted.  It suffers from the "put
an id on it" that makes working with <label>/<input> a minor chore,
but otherwise is mostly just shifting things around.

The second one is a bit more annoying.  The additional syntax weight
of the CSS trappings add up a bit, even with only two options.

The third one is just more or less ridiculous.  The added syntax
weight really shows itself here, with three largish lines to express
what src-N does in 5 tokens.  The fact that the sizes are separated
from the sources is weird.  The fact that you can only use a few units
(because you're no longer able to say "evaluate these sizes in an MQ
context", so "em" units and the like are useless because they depend
on style resolution) is very confusing.

This is a subset of CSS, yes, but the line dividing "what you can use"
from "what you can't" is rather windy, rather than being clear-cut and
simple.  People will regularly get this wrong.

Any argument that this is simpler to author, or easier for CMSes to
deal with, is rather laughable.  It's just as hard, if not more so.



A further, and kinda killer, problem with this is that it *can't be
reasonably polyfilled*.  I know as much as anyone that designing
around polyfills is often too limiting, but seriously, polyfilling
this requires a full CSS parser.  What this actually means is that
people will be using custom attributes and PictureFill or whatever for
a long time.  They'll be polyfilling for a long time regardless, but
the problem here is that they wont' be using a syntax compatible with
the real solution.

The one benefit of this proposal is that it potentially lets us
preload unrelated CSS images, if they happen to match the patterns we
specify (inline, id or class selector, etc.).  That sounds like
something that would be good to do regardless, but doesn't by itself
buy us enough benefit to justify the rest of the pain of this
solution.

~TJ