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

[Tab Atkins Jr.]

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

Right; I'm saying it doesn't matter.  Just mentally substitute the two
if you want.  I was specifically comparing a reasonable solution to
the provided use-cases (src-N) to PreloaderCSS, not srcset.

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

Here's Christian's example (adjusted to use proper syntax):

<style>
@media (min-width: 480px) {
  .artdirected { content: replaced attr(src-small url); }
}
@media (min-width: 600px) {
  .artdirected { content: replaced attr(src-medium url); }
}
@media (min-width: 800px) {
  .artdirected { content: replaced attr(src-big url); }
}
</style>
...
<img class="artdirected" src="foo.jpg" src-small="foo-small.jpg"
src-medium="foo-medium.jpg" src-big="foo-big.jpg">

Yeah, that's a bit of win on verbosity, but it still suffers from the
"invalid in every current browser, and hard to polyfill" problem, and
the "the line that separates usable CSS from unusable is hard to see".
 (And note that this doesn't do density negotiation.  To make *that*
work, we'd have to add an "image-set" type to attr().)

The problem is wanting to spread breakpoint information around in
several parts of the page, but wanting to edit it in only one place.
We can solve this directly, and the CSSWG is fairly supportive of the
generic approach for doing so.  We can hack around the issue by trying
to make it less painful to put into everything MQ-dependent into one
place, but we're just skirting the issue.  We added Custom
Properties/Variables for a reason, and that reasoning applies
identically to MQs, so we should just embrace it and stop pretending
that MQ maintenance is a problem.

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

It doesn't require syntax highlighting.  While the most complex
possible case needs a little getting used to before it's easily
readable, it's not so complex that syntax highlighting is necessary;
it's still pretty short and simple.

~TJ