The MP6 team has been working on recommendations…

The MP6 team has been working on recommendations for plugin authors who add a top-level icon to the dashboard’s main menu. We’ve investigated a number of options, all of which have their own advantages and disadvantages. In this post, I’d like to share the options we’ve considered in the hopes of generating a larger discussion about what would be the best possible solution for WordPress and for plugin authors. An example of the two SVG methods is available at http://codepen.io/joen/pen/otdkK.


Method A: CSS-colored SVG icon

This method uses SVG (vector, infinitely scaleable) icons that are embedded inline in the HTML. Using this method, the icon is able to inherit the color of the admin and change depending on customizations chosen by the user (a high-contrast admin theme for vision-impaired users, for example).

Pros
  • Clean, retina, and infinitely zoomable.
  • Only a single icon file needs to be created, no need for 2x versions or separate hover/active states.
  • With colors being controlled by the admin CSS, they will always match the core set of icons, as well as any further customizations made by the user.
Cons
  • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
  • For the CSS coloring to work, the SVG markup has to be cleaned up either manually or via an optimizer, adding some overhead to the creation.
  • The actual SVG markup has to be inline in the HTML. Hard to cache, requires core changes, potential security concerns.

Method B: CSS background-image SVG icon

This method also uses SVG icons for infinite scalability, but is applied via the CSS background-image property. Using this method, colors must be selected by the plugin author, and a separate file must be created for each color.

Pros
  • Clean, retina, and infinitely zoomable.
  • No security concerns (that we are aware of) with SVGs when used as background images.
  • No WordPress core changes are necessary.
  • SVG files can be used directly from Illustrator, no editing of the SVG necessary.
Cons
  • SVGs won’t render in IE8 and below. A number of possible solutions are discussed below.
  • Multiple files must be created for normal, hover, and active states.
  • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

Method C: PNG icons (the “no-build option”)

Alternatively, plugin authors could specify new MP6-style icons in the PNG format, using the same technique they use currently.

Pros
  • Universal browser support.
  • No WordPress core changes are necessary.
  • No security concerns with PNG.
Cons
  • Multiple files must be created for normal, hover, and active states.
  • Two sets of icons must be created in both 1x and 2x versions for retina displays (and more, when higher-than-2x displays appear).
  • With colors being controlled by the plugin author, they won’t match any customizations the user has made (a high-contrast admin theme for vision-impaired users, for example). Plugin authors must be mindful to use the colors recommended in the MP6 style guide (and creative plugin authors could use any colors, gradients, or styles they want).

SVG Browser Support

Internet Explorer 8 and below have no native support for SVG files. Icons in the SVG format will not display in IE8 and below as a result.

  • Modernizr’s .no-svg class could be used to specify PNG fallbacks.
  • A number of polyfills attempt to add SVG support to these browsers (we haven’t tried them).
  • We could adopt a Google Apps-style browser support policy for MP6, supporting the current and previous major release of each browser. This would drop IE8, but make room for the many new clients we’re supporting: mobile versions of Chrome, Safari, Firefox, and IE; and the Android and Blackberry browsers. We don’t know what IE8 usage is like among WP users, though.

Conclusions

Method A, inline SVG, is the best option from the designer’s viewpoint — plugin authors include a single icon and all styling is provided automatically. MP6 makes dashboard customizations like a high-contrast admin theme for visually impaired users much simpler than the current admin design — and method A makes styling plugin icons as easy as the core set of dashicons. However, the technical hurdles and possible security concerns could be significant and we need more input on whether this method is practical.

Method B would be the next-best option — it would provide the primary benefit of using SVG icons (infinite scalability) without requiring changes to core. It would be significantly more difficult (though not impossible) for plugin icons to reflect user customizations, but would still require less manual work than creating separate sets of 1x and 2x PNG (method C).

We’re interested in any thoughts that you may have, especially if you’ve worked with SVG before and can offer insight on how we could implement method A successfully. If you know of any reason why any of these absolutely won’t work, feel free to rain on our parade. :)