What’s next for Dashicons?

First, a little history–the first icon set used in WordPress was a png/bitmap sprite. The sprite couldn’t scale, which became a problem as display resolution increased. To solve the scaling issue, WordPress version 3.8 introduced a vector-based icon set packaged in an icon font, which was the most common approach for the time.

Outdated Format

Icon fonts are now an outdated format. SVG icons present a number of advantages in terms of performance, accessibility, scalability, and ease of use. There have been attempts to convert Dashicons to SVG, but that hasn’t happened yet.

Modifying Dashicons requires using third-party tools and command-line processes, making the contribution process hostile to new contributors. Adding a new icon and updating the font requires several time-consuming and complicated steps. The desire to keep Dashicons as lean as possible for the sake of performance means any new icons must be considered by the core teams to determine if they are warranted. As a result, there are often requests for new icons that don’t get met, meaning that people aren’t able to access icons they need.

Proposed solution

Instead of building something new from scratch or converting the icon font, we can leverage work already done in Gutenberg to bring a more modern toolset for admin icons to the whole of WordPress. Gutenberg introduces an SVG icon system that includes a process for extending icon sets. This makes it easier for plugin and theme developers to incorporate any icons they’d like and allows for the tried and true Dashicons to remain part of WordPress’ future.

The design team would like to extend Gutenberg’s icon system to the rest of WordPress. An open source and actively maintained icon set such as Material Icons would serve as a base set. This will give us an established set of icons to work with right away, which can then be built on to accommodate WordPress admin, plugins, and themes. This will make it easier for everyone to access the icons they need while bringing a consistent experience across the entirety of WordPress.

Your thoughts

The design team needs your input. Right now, we’re trying to determine if this is the right direction, and then we’ll focus on implementation details. Let us know what you think!

  1. Does this approach make sense?
  2. Are there alternate approaches we should consider?
  3. What should we keep in mind as we start planning?
  4. How does this impact users, developers, and teams?