jasmussen
commented
6 years ago 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
cathibosco
Zodiac1978
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