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

[Timothy Hatcher]

On Nov 15, 2013, at 1:28 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:

> On Fri, Nov 15, 2013 at 1:05 PM, Timothy Hatcher <timothy at apple.com> wrote:
>> On Nov 15, 2013, at 12:30 PM, Tab Atkins Jr. <jackalmage at 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.

I was saying srcset would naturally better here instead of <style> in a world where src-N does not exist.

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

You conveniently left out the nice part of Christian's proposal, or didn't notice it. Using attr() allows the style rules to be written generically by only defining the breakpoint media queries in the <style>. The image URLs and sizes are not in the <style> they are in the meaningfully named HTML attrs. So classes can be used instead of ids and used for all or groups of similar images. Yes writing the examples like you did does require a <style> per image and is not a win. Nothing stopes one-off images though.

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

If an attribute requires syntax highlighting to be understood, you failed. No other HTML attributes really require attribute level syntax highlighting, except maybe style or onclick and friends. But even those are not syntax highlighted.

I was merely saying: you get better looking code for "free" with <style>. CSS syntax highlighters already understand CSS and media queries. No tool changes required.

— Timothy Hatcher