[wp-trac] [WordPress Trac] #31352: Media icons are not retina friendly

[WordPress Trac]

#31352: Media icons are not retina friendly
-------------------------------------------------+-------------------------
 Reporter:  iseulde                              |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  4.2
Component:  Media                                |     Version:  3.9
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch ui-feedback needs-testing  |     Focuses:  ui,
  dev-feedback                                   |  administration
-------------------------------------------------+-------------------------
Changes (by joemcgill):

 * keywords:  needs-patch => has-patch ui-feedback needs-testing dev-
               feedback
 * focuses:   => ui, administration


Comment:

 [attachment:31352.diff] gets the ball rolling on this by adding
 @melchoyce's dashicon files (optimized in [attachment:dashicon-media-2x-
 optimized.zip]) to the `/wp-includes/images/media/` directory and
 referencing them in `srcset` attributes in media templates by adding an
 option to views.js when an icon is present.

 Concerns:
 * At the moment, the new icon files do not match the 1x versions already
 in use: https://cloudup.com/cAs9F7XWMAQ. We either need to update both or
 change the new 2x files to relate to the ones already in core. I would
 defer to Mel here.
 * Using `srcset` with x descriptors has pretty good, but not complete
 browser support: http://caniuse.com/#feat=srcset. If we wanted to provide
 support for all browsers, we would need to include a polyfill. Not sure we
 want to add a js dependency here, so I opted not to.
 * There's probably a more robust way to take the name of the 1x icon to
 create the 2x file name than what I've done in the inital patch, but it's
 a decent proof of concept.

 Alternate solutions considered:
 * Simply replace the current icon files with the 2x versions and serve
 oversized images to those who don't need them. Not ideal, but less markup.
 I wouldn't recommend this, but it's an option.
 * Using SVGs. I couldn't find any prior art in the admin for using inline
 SVGs in the UI. There are several places where we use SVGs as background
 images via CSS, but not inline. Ultimately, this would be an ideal case
 for using SVGs but there have been
 [https://core.trac.wordpress.org/ticket/26650#comment:54 concerns
 expressed] with doing so.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/31352#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform