- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 15 Nov 2013 12:30:35 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: "Jukka K. Korpela" <jkorpela@cs.tut.fi>, Markus Ernst <derernst@gmx.ch>, whatwg <whatwg@lists.whatwg.org>, Markus Lanthaler <markus.lanthaler@gmx.net>, Ryosuke Niwa <rniwa@apple.com>
On Tue, Nov 12, 2013 at 10:40 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Nov 12, 2013 at 9:50 AM, Adam Barth <w3c@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
Received on Friday, 15 November 2013 20:31:21 UTC