RICG-newsletter-2015-02-23.html

<h1>Crazy Eights</h1>

<p><em><strong>Teaser:</strong> Firefox gets respimg! Drupal gets respimg! Ev-er-y-bo-dy gets a respimg!</em></p>

<h2>38 Special</h2>

<p>Firefox users! Belatedly elate! Your images will soon be very lightweight.</p>

<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1017875"><code>picture</code></a> and <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1018389"><code>srcset</code></a> have been <a href="https://twitter.com/FirefoxNightly/status/567870148763209728">turned on by default in Firefox Nightly</a>, and are slated for Firefox 38 — release date: <a href="http://release.mozilla.org/planning/2015/01/13/release-schedule.html">May 12th</a>.</p>

<p>What is it about version 38s? Is their greatness innate? The first responsive image implementations landed in <em>Chrome <strong>38</em></strong> and Opera, uh, 25 <a href="http://us8.campaign-archive2.com/?u=c988d9ca55d5d09e73a7dc993&amp;id=58a0665da3&amp;e=[UNIQID]">back in October</a>.</p>

<p>The wait for Gecko respimg was a bit longer than anticipated; issue-owner John Schoenick left Mozilla for Valve back in November. But Josh Matthews picked up where John left off and succeeded this week in pushing the implementations across the finish line.</p>

<p>Huzzah!</p>

<h2>Drupal for your pupils</h2>

<p><a href="https://www.drupal.org/node/2260061">Responsive image support landed in Drupal 8 this week</a>. I’ve played with the implementation a bit and it’s fascinating to see how it differs from <a href="https://wordpress.org/plugins/ricg-responsive-images/">WordPress’</a> — whereas the WordPress respimg plugin tries very hard to keep things simple and automagic, Drupal’s support is much more structured, providing developers with tremendous control (but requiring more setup).</p>

<p>Next up for Drupal: <a href="https://www.drupal.org/node/2334387">a UI</a> to make that control accessible to people who don’t like mucking around in <code>.yml</code> files.</p>

<h2>WebKit, slow and steady</h2>

<p>Don’t look now, but Yoav is persistently laying the foundations for respimg in WebKit. Exhibit A: <a href="https://html.spec.whatwg.org/multipage/webappapis.html#microtask">microtask abstractions</a>, which saw <a href="https://bugs.webkit.org/show_bug.cgi?id=137496">a new batch of patches</a> this week. Let’s be honest: while I might be able to mumble a few vague words about how microtasks enable <a href="https://bugs.webkit.org/show_bug.cgi?id=134488">asynchronous image loading</a> in response to <a href="https://github.com/ResponsiveImagesCG/newsletters/blob/master/RICG-newsletter-2014-07-11.md#responsive-elements-in-blink--complete-picture-implementation-imminent">changing media conditions</a>, I wouldn’t recognize a microtask abstraction if it hit me in the face. But! I trust Yoav when he tells us that microtask-in-WebKit progress is respimg progress: slow, steady, and inexorable.</p>

<h2>Client hints in Blink?</h2>

<p><a href="https://github.com/igrigorik/http-client-hints">Client Hints</a> move the complexities of alternate resources, <code>x</code> descriptors, and <code>w</code> descriptors out of <code>srcset</code> attributes and into HTTP headers. Using Client Hints, markup can point to a single <code>src</code>. Browsers may send various “hints” — about their <code>device-pixel-ratio</code>, the layout width of the image, or their maximum download speed — as headers on the request for that <code>src</code>; the server can then use those hints to choose an alternate, more appropriate resource to send in response.</p>

<p>Yoav posted an <a href="https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/vOgv-TqefsA/o_fEsy8RFcwJ">intent to implement thread</a> about Client Hints over on blink-dev this week. Let’s see where it goes!</p>

<h2>Automatically optimal compression</h2>

<p>Artisanal-ly “Save for Web…”-ing every image by hand is fine for bespoke websites, but automated image compression is the name of the game for anything larger. Two great, recent, developments on that front:</p>

<ol>
<li><a href="https://github.com/rflynn/imgmin">imgmin</a> — the tool that lets you standardize image quality around an objective metric, rather twiddling an arbitrary and mysterious 0-100 encoder knob — has <a href="https://github.com/rflynn/imgmin/pull/43">integrated the <abbr title="structural dissimilarity">DSSIM</abbr> metric</a>. <a href="http://en.wikipedia.org/wiki/Structural_similarity">Structural (dis)similarity</a> is <a href="https://github.com/rflynn/imgmin/issues/30">Kornel Lesiński’s favorite image quality metric</a>; therefore it is also mine.</li>
<li>Dave Newton is constructing a <a href="https://github.com/nwtn/image-resize-tests">massive set of tests</a> for all of <a href="http://www.imagemagick.org/">ImageMagick</a>’s compression and conversion options. These tests are the raw material for an upcoming <a href="http://www.meetup.com/Toronto-Web-Performance-Group/events/220287399/">talk</a> and article on the subject – I can’t wait!</li>
</ol>

<h2>Grab bag</h2>

<ul>
<li>Matt Wilcox wrote up his <a href="https://mattwilcox.net/web-development/keeping-srcset-and-sizes-under-control">fantastically practical method</a> for picking image breakpoints and authoring <code>srcset</code> and <code>sizes</code> markup a few months back; I somehow missed it. Oops! Go read it! It’s great!</li>
<li>SVG savant Sara Soueidan published a great thing on <a href="http://sarasoueidan.com/blog/svg-picture/">using <code>picture</code> to serve SVGs with PNG fallbacks</a>.</li>
<li>A bit of follow-up from last week: <a href="https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images/issues/51">Wordpress settled on a default <code>sizes</code> value</a> and it’s eminently practical. That default is also <a href="https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images/issues/30">settable by theme authors</a> (though they’re <a href="https://github.com/ResponsiveImagesCG/newsletters/issues/154#issuecomment-75567634">still tinkering</a> with how that should work), and adjustable on an image-by-image basis via a sorta-janky/sorta-genius <code>data-sizes</code> attribute. Neat.</li>
<li>The <code>srcset</code> syntax and/or <code>sizes</code> attribute <a href="https://github.com/ResponsiveImagesCG/picture-element/issues/258">might be useful for</a> <code>video</code> <code>poster</code>s?</li>
<li>After his <a href="http://hookedoncode.com/responsive-images-are-here-now-what-by-jason-grigsby-notes-from-an-event-apart-talk/">An Event Apart Atlanta talk</a>, Jason Grigsby set about writing down a bunch of respimg implementation best practices in a series of blog posts. Here’s the <a href="http://blog.cloudfour.com/responsive-images-are-here-now-what/">first</a> — an introduction, of sorts — and <a href="http://blog.cloudfour.com/responsive-images-audits/">here’s the second</a>, which outlines the extremely sensible, constantly-overlooked step of auditing what you have before deciding where to go, re: images on a website.</li>
<li>Here are a couple of Rails respimg helpers — <a href="https://gist.github.com/mrreynolds/4fc71c8d09646567111f"><code>srcset</code> with <code>w</code>s</a>, <a href="https://gist.github.com/henrik/2ddcc6ab8c66e7c49305"><code>srcset</code> with <code>x</code>s</a> — if you’re into that sort of thing.</li>
</ul>

<p>See you in a couple of weeks!</p>

<p>—eric</p>