New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block icons SVGs are not reusable #9647

Open
caxco93 opened this Issue Sep 6, 2018 · 14 comments

Comments

Projects
None yet
10 participants
@caxco93
Copy link
Contributor

caxco93 commented Sep 6, 2018

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.

@caxco93 caxco93 referenced a pull request that will close this issue Sep 6, 2018

Open

Created a new package containing all icons #9648

3 of 4 tasks complete
@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Sep 6, 2018

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

This comment has been minimized.

Copy link
Contributor Author

caxco93 commented Sep 6, 2018

I think they would belong there as well

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Dec 14, 2018

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:

<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>

screenshot 2018-12-14 at 11 03 28

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

This comment has been minimized.

Copy link
Contributor

afercia commented Dec 14, 2018

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

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 23, 2019

@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

This comment has been minimized.

Copy link
Contributor

jasmussen commented Jan 23, 2019

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.

Perhaps it's time we 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 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

This comment has been minimized.

Copy link
Member

chrisvanpatten commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor

jasmussen commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor

mapk commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor

jasmussen commented Jan 23, 2019

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

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Jan 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

caxco93 commented Jan 24, 2019

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

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Feb 12, 2019

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

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment