Resize/Optimize svgs

[field2]

In order to make Dashicons more compatible with being served in SVG format in future versions, we need to scale them up to 24x24 pixels. This requires careful adjustment of icon vectors to ensure that vertical and horizontal edges are aligned to the pixel grid wherever possible. Checkout the branch https://github.com/WordPress/dashicons/tree/test/resized-icons to work on this

[jasmussen]

I applaud the fearlessness with which you're proceeding, from what was mostly a "future considerations" idea that I posted in Slack.

But proceeding might require a bit more careful planning, both in order to roll it out to WordPress, and to ensure that it's done in a way that addresses goals. If we just scale up the existing icons to 24x24, we won't just be able to drop-in the icons in WordPress and have it work, so we have to consider a transition path also.

Why 24px could work for us

To rewind a bit, here are some of the reasons why I believe that 24x24px is a good size for an icon set.

First off, we’re approaching a point where we need both large icons, and medium sized icons. Large for things like blocks, alerts, or primary navigation. Medium sized icons for things like sidebar navigation, or helpful icons to sit next to labels ([trashcan] Delete ).

The big challenge here is you can’t really do that with just one icon set. 20px is decent for the “medium” size, but at 2x (40px) it’s too big for the large size. 1.5x (30px) would cause some pixels to be drawn at .5 coordinates, causing blur, hence the need for drawing a set at two sizes.

If we were to adopt 18px and 24px, it’d give us 12px for really tiny sizes (.5 * 24), 18px for medium, 24px for large, 36px for extra large, 48px for huge. All these would be even numbers, making pixel precise designs easier.

Secondly, a number of other icon sets have adopted these sizes, including Android. This both gives us a template for how to move WordPress into a mobile future (do what they do), but it also makes our icon set optically compatible with the material design icon set, which is pretty vast and also open source.

Thirdly, the 24px set would be the primary set. The 18px set would be a subset, based on the 24px set. We could essentially scale down the 24px version, see if it need hinting (lots of solid icons, like tags, probably wouldn't need any hinting), and then draw only hinted versions for the icons that didn't scale well.

We would be able to put together a neat grunt process to help us here. We could have a source directory with something like calendar.svg @ 24px and calendar-18.svg @18px. You’d then also have something like tag.svg @ 24px, but not need a separate 18px version as that icon would scale nicely.

Through a nice icon script you should then end up with something like

<Dashicon icon="calendar" size="18" />

This component would then just pick the 18px version if that existed, otherwise just scale down the 24px version to .75x.

Preriquisites to get there

In the near future, WordPress needs Dashicons as they are. That is, an icon font, shown at 20px.

If we believe the future is a 24px base set with 18px as a smaller optional set with hinted versions, then WordPress itself needs design adjustments to accommodate these new sizes. Not only that, but WordPress needs to move from the icon font to the SVGs. But given we are thinking about a scripted component to output the 24px version by default, and a special 18px if requested, then WordPress itself also needs to move towards being more JavaScript based. Although this is a stated goal, WordPress is not there yet.

Gutenberg can help lead a path forward here, given that it's already JavaScript-based and uses a component that outputs SVG. As such, Gutenberg could certainly start to take advantage of the new sets even today. But given the phase Gutenberg is in at the moment, our need for new icons is decreasing, and it's not a given that we'll be able to swap out icons wholesale.

So to summarize:

• Still need 20px set, to hold over in a transition phase
• Needs WordPress to be more JavaScript-based, to employ SVG icons in a sensible way
• Needs WordPress design tweaks across the board to accommodate the new icon sizes

Given those preriquisites, it seems there's definitely a place for the new icons in WordPress, but that it's not going to be a "rip out the carpet" kind of replacement.

Proposed approach

Gutenberg is the first core project that will be able to take advantage of the new sizes. As such, that could be the first test case for this project.

Before too much work starts on the icons themselves, some structural work should be done. We should have three source folders, one for legacy, one for 24, and one for 18.

Then the grunt script should be updated, so that every icon in the legacy folder is output to the icon-font for WordPress compatibility.

The React component that the grunt script creates could then be rewritten to output the appropriate icon:

• would output the 24px version if available, and the 20px if not
• would be output if the 18px version was available, but scale down the 24px version if not

This would allow us to experiment with the 18/24 versions in Gutenberg, and slowly build up the set if we find it works.

In a potential future where the entire admin is then SVG'ed, we could then start to retire / deprecate the 20px set in a non-disruptive way, simply by redirecting any icons requested at 20px to the 18px set, perhaps even with a 1px padding to make sure it fits. We could even keep the icon font around for plugins, in an interim phase.

What do you think?

[field2]

I think you're spot on. Thank you for this comment! It will be super helpful as we're working through the resizing phase of this project.
The branch I referenced in the first post is old; @cathibosco and I have been working on https://github.com/WordPress/dashicons/tree/try/icon_remastering. Considering the issues you've raised, would it be best to move forward with that branch or should we start a new one?

[jasmussen]

Work already done should definitely not be thrown away! Keep those SVGs around.

However I do think we should pick a subset, say 5 of the most "important" dashicons, and remaster those in 24px, and then draw the 18px versions (if they need them). Given those, I would volunteer to start work on a branch that would tweak the grunt process and output the new stuff. I can't promise exactly when I can start work as I have a fair bit on my plate, but that seems like it would be a good approach.

By the way, here is a link to the Google Material Icons repository, where you can see how their 18 and 24 versions are stored: https://github.com/google/material-design-icons/tree/master/device/svg/production

Note how some of their icons are drawn in both 24px and 18px, like the widgets icon. 24:

18:

Yet notice how others are not drawn in 18px, presumably because they are deemed good enough at that size even if scaled on the fly. Like the Bluetooth icon, for example. 24:

Scaled down automatically to 18 with no hinting:

☝️ Illustrator adds a little extra heavy blur in that screenshot, so it's not entirely web accurate rendering. But it illustrates the point pretty well I think.

Another step probably worth doing, is creating an icon template for the new 24px artboard, so we know roughly how big the icon should be, optically, within the 24px canvas. We can use the Gridicons template as a starting point: https://github.com/Automattic/gridicons/blob/master/sources/icon-template.ai

Also worth reading the Material Design guidelines for inspiration: https://material.io/guidelines/style/icons.html#icons-system-icons

[cathibosco]

This template is extremely helpful - thank you. I will do all that I can to help get 24X perfect so we can inch closer to SVG.

[Zodiac1978]

@field2 @jasmussen @cathibosco Is this ticket resolved and can be closed? There is one open issue mentioned with #327 - is this the reason for still being open?

[jasmussen]

Sure, let's close this one, we can always reopen. I left a comment in #327 with a little context.