Block icons SVGs are not reusable

[caxco93]

Is your feature request related to a problem? Please describe.
Related PR: #9648.

I think we should extract the SVG icons to another package, maybe @wordpress/icons. This will increase their reusability and maintainability. Right now I was looking at #9642 and it would require to declare the same SVG again for the MediaPlaceholder icon.

Describe the solution you'd like
Create a new package @wordpress/icons to hold all icons to increase reusability.

[ZebulanStanphill]

Nice! Notably, there are currently some icons missing from the embed block. (The generic ones for brands without a unique icon and the brand-specific ones.)

Should brand icons be included in this package or in a separate package?

[caxco93]

I think they would belong there as well

[afercia]

Was going to create a new issue and saw this one 🙂 I'd totally second to make all the Gutenberg icons reusable. Many of the new icons are hardcoded in the various components, for example:

gutenberg/packages/components/src/panel/body.js

Lines 60 to 67 in a617aee

	<SVG className="components-panel__arrow" width="24px" height="24px" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
	<G><Path fill="none" d="M0,0h24v24H0V0z" /></G>
	<G><Path d="M12,8l-6,6l1.41,1.41L12,10.83l4.59,4.58L18,14L12,8z" /></G>
	</SVG> :
	<SVG className="components-panel__arrow" width="24px" height="24px" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
	<G><Path fill="none" d="M0,0h24v24H0V0z" /></G>
	<G><Path d="M7.41,8.59L12,13.17l4.59-4.58L18,10l-6,6l-6-6L7.41,8.59z" /></G>
	</SVG>

In this specific case, as plugins can add their own panels in the sidebar, it makes sense to allow them to also reuse the Gutenberg icons. Besides this specific case, it would be great to have all the icons reusable via a component à la Dashicon.

[afercia]

I'd propose to make this issue related to all the icons, not just the block type ones.

[gziolo]

@jasmussen @mapk @karmatosed - any thought on this one? Do you feel like this is something that would help to work with icons in WordPress codebase?

[jasmussen]

Perhaps it's time we start talking about icons as used in Gutenberg, and indeed WordPress, as a whole.

For now we have used Dashicons because it's the WordPress icon set. But this has not scaled tremendously well, and the icons are small and designed for older screens and interfaces than we use widely today. So we eventually adopted the Material icon set for block library icons, to make it trivial for plugin developers to quickly and easily pick a unique and legible icon that fits their block.

We could adopt icons, such as Material, of the relatively standardized 24x24px size for all of Gutenberg to mitigate these same issues for not just the Block Library but for the entire editor. The goal would be an easily reusable library as proposed in this ticket, but one where all icons are of the same size.

Pros:

• An ever-growing set of open source & well-designed icons
• Larger icons means better legibility and better accessibility for sighted users
• 24x24 scales well to mobile, where icons are usually multiples of 24 (Android uses 48, 96).

Perhaps most importantly, it removes the bottleneck that is responding to icon requests through manual labor. Despite all the hard work we've put in to improving the build process for Dashicons, it's still an arduous process. The process is now a matter of creating an SVG and typing a command line argument and all files are processed and built from that, but even then the icons have to be imported into Gutenberg and WordPress. For a plugin developer, this is an untenable process that will likely lead them to adopt different icon sets regardless the improved process.

So how do we keep some of the WordPress "identity" if we adopt a set not built here?

We could do that by keeping Dashicons, but resizing & refining them to optically match (addressing WordPress/dashicons#255). We'd essentially have two icon sets, although we could probably componentize them both so they would appear as one set for the plugin developer user. The big set would be based off the Material icons and be as automated as we can make it. The other set would be a reduced version of Dashicons, with direct duplicate icons removed (align left, align center, and so on), but keeping icons that are important to WordPress due to history, branding, "the WordPress feel", or even just to include icons that are never likely to land in the Material icon set, such as "Align Wide".

It feels like it could help simplify the icon process overall, increase legibility, and smooth out many of the process bumps we currently have.

Many of the previous thoughts posted here still apply.

[chrisvanpatten]

I think one thing that's important here is to consider this holistically in the context of the entire WordPress project. Embracing Material Icons in Gutenberg in a bigger way feels like a trojan horse to getting them used across WordPress, and I think that's a big enough topic that it should be raised in (at least) a design meeting. It primarily impacts Gutenberg now, but as Gutenberg expands outward it will slowly impact other areas of the project and it'd be better to head off those discussions now.

To be clear: I'm not necessarily opposed to Material Icons (or any other icon set), I just think it needs to be discussed outside of a Gutenberg context before charging forward, to be fair to other folks working on design problems outside of this repo.

[jasmussen]

I think one thing that's important here is to consider this holistically in the context of the entire WordPress project. Embracing Material Icons in Gutenberg in a bigger way feels like a trojan horse to getting them used across WordPress.

Strongly agree that it should be raised in a design meeting — even if it applied only to the block editor it would be worth bringing up. And yes, this would affect the rest of the UI — in hindsight that was not clear enough from my comment, and not at all sufficiently implied by the linked discussion thread on Dashicons. No reason to limit the improvements in consistency and legibility just to the block editor — if successful, this should apply to all of WordPress.

I have edited the previous comment to clarify. Thanks Chris.

[mapk]

I think that's a big enough topic that it should be raised in (at least) a design meeting.

I'll raise it in today's design meeting at 7pm UTC.

[jasmussen]

Awesome, I won't be able to attend as I'm putting kids to bed there but I'm always available async.

[melchoyce]

Staying on top of Dashicons has been a challenge — I would really love to see us adopt an open source, third-party icon library designed for interfaces that we didn't need to maintain. (Honestly, the most I'd want to do it bundle updated assets every couple of core releases.) Material's pretty versatile, and their focus on mobile iconography could also come in handle in the future if we double-down on improving our responsive experience.

[caxco93]

I am very much in favor of having it discussed in a meeting. Any news, @mapk?

[gziolo]

Related discussion on WordPress Slack (requires registration at https://make.wordpress.org/chat/):
https://wordpress.slack.com/archives/C02S78ZAL/p1549904844009000

[melchoyce]

Post just went up: https://make.wordpress.org/design/2019/02/12/whats-next-for-dashicons/

[gziolo]

@melchoyce - is it going to be further discussed at one of the Design team meetings? I think it's something that we really need to be solved in Gutenberg as we already have some places in the codebase where we duplicate the same icons .

[mapk]

@gziolo I believe we're at a standstill right now on icons. We can't move forward with Material icons until something is resolved between the licenses, and so we're blocked. I'm hesitant to make all new icons reusable right now seeing as many of them are from Material.

Any of the custom icons created for Gutenberg should be made reusable.