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

[Adam Barth]

On Fri, Nov 15, 2013 at 12:30 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> 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.

Do you have an alternative proposal aside from src-N?  Recall that
src-N has been rejected by WebKit and therefore is no longer viable.

Adam