[wp-trac] [WordPress Trac] #21019: Retina All the Things

[WordPress Trac]

#21019: Retina All the Things
----------------------------+------------------------------
 Reporter:  matt            |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  3.4
 Severity:  normal          |  Resolution:
 Keywords:                  |
----------------------------+------------------------------

Comment (by nacin):

 I've been thinking about how we should be handling retina images for a few
 days now. Ultimately, loading 2x images is not particularly easy. You can
 do it all via CSS, but that means you may need to know the height and
 width of the image (for background-size), and also the URL of the image.
 Not good when you want to potentially 2x every image on the page.
 Alternatives via JS could mean double-loading (1x then 2x).

 There are a number of interesting techniques out there. The one I've liked
 the most is https://github.com/adamdbradley/foresight.js, mainly because
 its dense readme is very informative, and its
 [https://github.com/adamdbradley/foresight.js/wiki/Challenges-for-High-
 Resolution-Images challenges] document clearly outlines a set of
 philosophies -- a manifesto, if you will. It also does a bandwidth check
 before deciding whether a device/browser should be served 2x images, which
 is appealing when a lot of retina devices are still operating over mobile
 networks.

 foresight.js does something like this:
 {{{
 <img data-src="imagefile.jpg" data-width="320" data-height="240" class
 ="fs-img">
 <noscript>
     <img src="imagefile.jpg">
 </noscript>
 }}}

 For search engines and those without JS, they get the standard 1x image.
 In order to get the 2x image, you have to pass the bandwidth test, and
 then the image tag can be set as either 1x or 2x.

 It is clever. But I don't entirely like this. It's not a great experience
 especially on a content-heavy page to need to wait for the DOM to finish
 loading in order to even get an HTTP request to fire in order for an image
 to be displayed — which would include regular 1x browsers too. (It should
 be noted that sometimes, HTTP requests for images don't fire until after
 DOM ready, but only sometimes.)

 I think the best thing is foresight.js with a twist: Since we can do
 bandwidth checks, we should forgo the idea of preventing a double-loading.
 (This crosses off the first bullet point on the challenges document.) And
 then we end up with something like this:
 {{{
 <img src="imagefile.jpg" width="320" height="240" class="fs-img">
 }}}

 Then we get an image, and then some JS can convert img.fs-img's src to
 -2x.jpg (or _2x, or @2x), and then they become sharper. It's progressive
 JPGs all over again.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21019#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software