Handling plugin icons in Gutenberg.

[abotteram]

Issue Overview

I've been working on the ellipsis menu item API #4484. I wanted to start work on implementing the icons that are displayed left of the menu titles, and I was wondering what the right approach would be to handle icons in the API.

Can icons be multicolor? Because that would mean passing a component containing a svg component would be the easiest way to go. Also this is an aesthetic choice, because it will determine the look and feel of the ellipsis menu.

If not using the dashicon maybe an idea. I looked at the dashicon for inspiration, and maybe, just maybe, extending the dashicon to accept icons that can be registered through a public api would be an option, so they can be easily reused. This could also be a new component of course but I thought using the dashicon as a multipurpose component throughout the entire app would be a nice way to go.

Summary:

1. Should icons from plugins be passed as react components?
2. Can icons be multicolor in the ellipsis menu?
3. Is creating some sort of api for icons an idea, so a single identifier can be used throughout a plugin to reuse an icon.

I've talked to @jasmussen about this, but he didn't have a definitive answer. That's why I'm starting this discussion.

Todos

• Tests
• Documentation

[youknowriad]

In several places "block icons" and the IconButton component we accept two types of icons:

• Dashicon strings
• Any React element

If we detect a string we use Dashicon component with the string and we just render the React element in the other case. We should probably continue similarily.

[mtias]

I think for these we might want to support an image as well. Thoughts @jasmussen ?

[abotteram]

@youknowriad Any react element? Shouldn't there be some safeguards for that, if that is at all possible?

[youknowriad]

@xyfi I don't see the necessity of a safeguard. People will try things and it will break "visually" if it doesn't match. And like you said, It's very hard to add restrictions if you allow custom HTML/element.

[jasmussen]

I think for these we might want to support an image as well. Thoughts @jasmussen ?

I encouraged Alexander to open this ticket because I think it's a worthy discussion to have exactly for this reason.

Personally, deeply personally, I would love it if plugin devs could only use either the WordPress bundled icon set, or pass their own SVG as an inline react element. That way we'd always have consistent single-color icons that received proper hover/active/focus styles inherited from the UI itself.

However I understand that there are ideas I haven't yet thought of, that might require a multi-color icon, and possibly even legitimate use cases that warrant an out-of-style icon. As such I will put my personal feelings aside for this one ;)

If we detect a string we use Dashicon component with the string and we just render the React element in the other case. We should probably continue similarily.

An idea — let's say you passed a clever little icon-sized validation component here, like a spell-checker or a Google AMP validator or what have you — could it sit there as a checkmark if everything validated, turn into a cross with a tooltip if not, and even spin if it was "working"?

[mtias]

We can try doing just svg icons, it simplifies a lot (hi-dpi, etc) while still supporting colors if necessary.

[mtias]

If we detect a string we use Dashicon component with the string and we just render the React element in the other case. We should probably continue similarily.

I don't think we should allow Dashicons for this case, as it could really muddy the meaning of the symbols when they apply to blocks and extensions alike. Custom svg logo or nothing might be better.

[jasmussen]

👍 👍

I think it would be good to start simple, and then we can adjust as the need presents itself.

[karmatosed]

I would 👍 starting simple. From an experince view the one limit I would like us to add is no multiple colouring. I feel we can set that as a pattern and it benefit the experience. As colour alone shouldn’t be used to show state, I think it’s an extra that would reduce the experience and even cause visual issues. Least this way we can be sure of contrast for example.

[abotteram]

Thank you for your elaboration. I'll stick to a custom SVG element passed as a component. Iteration is key here.

Does that mean this issue can be closed, or would you like to keep this open for future debate?

[mtias]

Yes, let's close. We can reopen if something else comes up.