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

On Fri, Nov 15, 2013 at 1:05 PM, Timothy Hatcher <timothy@apple.com> wrote:
> On Nov 15, 2013, at 12:30 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 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>
>
> The simple case is a case srcset (the DPR parts) solves and I'd argue should
> be used here instead.

You can s/src-1/srcset/ this example; the two are identical for this use-case.

>> 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.
>
> Sure you can use ids. But the idea behind the CSS proposal was to allow
> better sharing of the breakpoint media queries.

Not really.  PreloaderCSS gives you two choices, both bad:

1. Put the image sources in a <style> next to each <img>, thus
repeating your layout breakpoints in the MQs multiple times. (This
weakness is shared by src-N.)
2. Or put all your image sources in a single <style> block somewhere
in the page, requiring people to look in two places for image sources
and virtually guaranteeing that the fallback url in <img src> will be
ignored and fall out of sync.  You still have your breakpoints in at
least *two* places though - once in your in-page <style> block, and
once in your external CSS.

I think #1 is better, as we can solve it with Custom MQs/MQ
Variables/whatever, which the CSSWG is already kosher with (and I'll
be writing up soon).  Once that's solved, much of the problems of this
approach disappear for both src-N and PreloaderCSS.

> Using ids doesn't share,
> using a class would. Src-N you have no choice but to repeat everything
> everywhere.

Why would you be using classes?  Most images that you need to make
responsive are one-off content images, like the big picture in
<http://www.bostonglobe.com/magazine/2013/11/10> (and maybe the
picture in the sidebar).

The only reason to use a class is if:

1. You're displaying the exact same image multiple times on the same page.
2. *And* it's for some reason appropriate/important as a content
image, rather than just using a standard (and totally okay) CSS
image-replacement method.
3. *And* it's large enough that you actually care about the increased
weight from higher densities.  (Gimme an 8x retweet arrow; who cares?)

I respectfully submit that images matching all three of these criteria
are so low-occurrence as to be mistaken for noise.

Even on a site that uses a *lot* of images that could benefit from
responsiveness, like Vogue <http://www.vogue.com/>, all of them are
one-offs.

So, let's be honest here - using classes in PreloaderCSS was *never*
something people were actually going to do.  It's all about IDs and
just shifting all the src-N stuff from attributes to an adjacent style
block.

>> These examples... do not look good.
>
> They look better in an editor. CSS is syntax highlighted. Src-N's format
> isn't and likely would never be — as most HTML attributes aren't.

While "the tools will save us" is not generally a useful argument,
syntax highlighting is easy peasy.  I could add this to Sublime's HTML
highlighter in half an hour max, and it would only take that long
because I'm still not super-comfortable with the authoring format.
"There's no syntax highlighting *yet*." isn't a very useful argument
here.

~TJ

Received on Friday, 15 November 2013 21:29:11 UTC