Add an Icons block

[mtias]

A common tool that many block libraries are adding is a block to insert icons (usually svgs) with some color and sizing tools. This is appearing repeatedly in libraries to the point that it makes sense to consider a more general solution in core, which ideally handles markup and accessibility consistently. We could make this block easy to extend (register new svg libraries or remove them) and it can be the basis for other more specific / niche tools (like social logos, etc).

[richtabor]

For reference, here's an overview of the Icon block in CoBlocks:

[senadir]

I'm looking at implementing this currently & have some questions of how much features for it is required to consider it ready?

I can see that resizing & Icon search are an essential start
this raises other questions like

• what will be searched for, what Icon library are we going to use?
• what is the limitation in regarding to customizing

I can start with a simple implementation of getting both the resizing and a simple search using dashicons

[enriquesanchez]

hey @senadir! 👋

I took an initial stab at exploring how the placeholder state of this block could look like:

A few things to note:

• I haven't yet thought about what options would be available on this block's toolbar, this is why those are empty in the mockup.
• I feel we should allow the user to filter by or select icons from different libraries. I'm still not sure how this could work (I assume we can start by including open source icon libraries) and if this is something we should leave for the block settings sidebar.

Before we move on, I think we should figure out what settings and customization we'll offer. Would love to hear what you think.

[mapk]

Looking really good, @enriquesanchez. I like the concept of searching for an icon first before stepping into the actual block, and I think your exploration helps communicate this. I have a bit of feedback.

1. Often times when adding an icon, it's probably going to be in context to additional text on the page. Maybe a feature content section of 3 columns, or some other area that may not provide a lot of room for a larger placeholder like this. It might be good to explore this placeholder in a more narrow setting too.

2. Selecting an icon seems to be a primary function of this block, so I'm hesitant to suggest just pushing it to the block settings sidebar. Maybe the list of icons after search shows them a lot smaller? This might help with space.

[enriquesanchez]

It might be good to explore this placeholder in a more narrow setting too.

That's a great point @mapk!

I think we can definitively go small without sacrificing functionality:

It will all depend on how many results we want to display. Depending on how many libraries we support, I assume that often times we'll have just a couple, but it doesn't hurt to plan for all scenarios.

Thoughts?

[mrwweb]

A few random thoughts to throw out early in the process from my experience using a lot of SVG icons in a few recent projects:

• @mapk beat me to highlighting usage in columns (Icon Block + Heading Block + Paragraph Block). That should definitely be expected. In that pattern, I would think people would also want to link icons. That would require both a field for link URL as well as potential styles for :hover, :focus, and :active.
• This might need to be a different icon block, but I just want to flag the likely desire for people to use icons inline and not just in block contexts.. In particular they can look good in Headings or Buttons. Sizing them as 1em by 1em can be really helpful in that context.
• If there are going to be built-in color controls, it will be really important to define the expectations for SVG files. Does it only support expanded paths? What if I made something like the flickr logo with two circle elements? (And multicolor icons 😱?)
• I would also be in favor or requiring icons to be on a square canvas for simplicity. Thinking about what an "icon" is, that may be a useful distinction in fact.

[onuro]

Right now Kioken Blocks does it like the following:

Would have always preferred a simpler approach though but I used React FontIconPicker component since plugin hosts around 7500 svg icons.

I also love how CoBlocks and Ghostkit handles it. Like how Ghostkit allow you inline select an icon within a block:

I use toolbar component for in-context icon changing for a block:

[enriquesanchez]

Hey @senadir! Are you still interested in working on this block?

I'm looking at implementing this currently & have some questions of how much features for it is required to consider it ready?

I think we should start with the most basic features and go from there. Based on everyone's feedback:

The block's placeholder should take up small space (because of nesting), so we should ask for the minimum:

• a search field
• list of results from where the user can select one

One thing we need to figure out is where to source the icons from. From the examples shared above, it looks like Ghostkit is using FontAwesome and Kioken Blocks is using React FontIconPicker. @mapk do you have any suggestions?

As for settings/features, I think we can start with:

• Size
• Color
• Style (will depend on the icon library we use, but I assume this will be "outlined vs. filled". Alternatively, we can go with no background and colored background)
  Link (URL and label for a11y)
• Replace icon

Anything else I may be missing?

[karmatosed]

One point I wanted to raise from the editor chat would be that I am not convinced supporting yet another icon set is a good idea. My vote would be stick to what Gutenberg already has for now.

[mapk]

@mapk do you have any suggestions?

Yeah, I wonder if would just be easiest to roll out with Dashicons? If we want to include an of the Material icons Gutenberg uses as well, as Tammie mentioned, that's cool too.

[enriquesanchez]

Thanks @karmatosed and @mapk!

[onuro]

@mapk do you have any suggestions?

Yeah, I wonder if would just be easiest to roll out with Dashicons? If we want to include an of the Material icons Gutenberg uses as well, as Tammie mentioned, that's cool too.

Thing is the Material Icons (as components) within GB is relative to the GB plugin version, meaning anything other than Dashicons may not be accessible fully by user based on if they use a WP core GB or the GB plugin (unless a kind of a full set is provided by GB universally just like Dashicons).

A case example is the vertical alignment Material toolbar icons. They're not accessible to WP - 5.2 GB but available with GB plugin active (as icon components).

[mrwweb]

+1 for providing a limited set of icons so long as the block is easily extensible for other sets. Again, it will be super important that the way to register new icons AND file requirements for icon SVGs be clearly documented (and therefore defined and worked out before implementation).

One other note: I can't find a reference, but long ago I recall it being stated somewhere that Dashicons were intended explicitly for the admin and not front-end usage on websites. It seems worth confirming whether that is still the case or not.

[melchoyce]

Yeah, I think something like Font Awesome might be better — open source, actively maintained, and designed for a variety of contexts.

[senadir]

@mrwweb creating an extending standard will not be a priority right now as the same with all other blocks, not until the current implementation is stable enough to allow third party integration to it

[CalumChilds]

Using an interface similar to that of IcoMoons' is a great idea.

I do disagree with you on not having any other icon packs included other than Dashicons, since it doesn't include enough variety to be useful on most websites. For this reason, I recommend including one other icon pack into WordPress. I think Font Awesome 5 Free would be best for this since it is open-source and has a wide enough variety of icons to be useful on most websites.

The selection.json format is good, although there are two things that I would add:

1. A filter where the user could select the weight(s) they want the resulting icons to be, and the ability for plugins/themes to add their own.
2. A feature allowing duotone icons to be added. I'm not sure how this would be done, but multiple icon frameworks have duotone icons (including IcoMoon and Font Awesome)

[cr0ybot]

I think Font Awesome 5 Free would be best for this since it is open-source and has a wide enough variety of icons to be useful on most websites.

You're probably right. I take back the mention of Dashicons, as I consider them deprecated at this point anyways.

Font Awesome is and has been the default icon set of the web for a while, for better or worse. It makes things a little complicated though when there is a closed, commercial aspect to the project. For example, duotone icons are only available with a Pro license. Another complicating factor is that Font Awesome 6 seems to be close.

I realize it's already been mentioned in this thread, but I think a better option is the Material Design icon set, which is what the @wordpress/icons library (note: separate from Dashicons) is based on (see #20284 (comment)) and has a set of simple guidelines that makes creating additional icons with the same look & feel somewhat simpler than Font Awesome. It also includes different styles, including duotone ("two tone"), and is completely free with no commercial aspect. I can't find a total number of icons at the moment, but I bet the number is at least close to or even surpassing the amount available from FA free.

I suppose another part of the reason I'd advocate pulling in Material over FA is that it could make the much larger icon set more readily available to theme and plugin authors that need to add icons for various reasons in the WordPress admin/editor. I realize that is only tangential to an icon library for a block but it would be useful.

[AlecRust]

Regarding Material Design icons (which sounds good to me) I believe this is the open source effort with a larger set:

https://materialdesignicons.com/

Used by large projects like Home Assistant.

[kraftner]

I think the discussion if/what icon library to include is at best tangentially relevant to this issue. What would be important is the infrastructure to add a custom set of icons as defined by the site/theme. Adding a default set may be nice but is not strictly necessary for an icon block to be useful.

[CalumChilds]

Regarding Material Design icons (which sounds good to me) I believe this is the open source effort with a larger set: https://materialdesignicons.com/

I would support using this icon set if it is from this website and not the official icon set from Google since the one @AlecRust included contains 26,000 icons (more than enough for an average website!) and unlike the official Google set, contains brand icons for non-Google services/products (such as the Facebook icon, which I think would be widely used within blocks.)

[cr0ybot]

I think the discussion if/what icon library to include is at best tangentially relevant to this issue. What would be important is the infrastructure to add a custom set of icons as defined by the site/theme. Adding a default set may be nice but is not strictly necessary for an icon block to be useful.

You're totally right. Regardless of any defaults, the big problem of how to import and store these icon sets is the thing that is most in need of a solution.

The IcoMoon example is just a data format, but it begs the question: regardless of the format, where is it stored, and how is it managed? Can a theme include a JSON file? What happens upon switching themes? Do they get imported into the database?

[Jabe64]

And what about custom icons? It needs to be considered as well.

[thatmikebal]

Has anyone explored an experience where we use something like the media library experience to let the user browse an icon library and choose what to save to their site so they can use it?

Think about how you can select playlists for offline listening on Spotify or even movies/shows for offline viewing on streaming services.

We wouldn't limit the user's options and we wouldn't have to worry about carrying the weight of a large icon library. Having a site-specific library would also allow the user to upload custom icons.

[dugyen]

Just a note, would be great if these icons were able to integrate with other blocks as well (buttons, media+text, etc).

Agreed, this would be very useful. For example, in a design like this:

Would love to see an icon block in core!

I would agree with you.

[dugyen]

It would be great if we could drag and drop icons and move any position ( middle, right, left, up, down) because current option cannot let us to locate the icon where user like to position it or drag icons.

[strarsis]

An icon block would ideally be an inline block that can be placed not only between blocks but also inside text.
Related issue: #10235

[Julianoe]

Not sure if this has been discussed elsewhere or not but imho icons could be considered design tokens. As such, theme/plugin developers should be able to add icons using equivalent APIs to the ones used for colors and font-sizes.

Another token that could be introduced is sizing. This would allow developers to define common sizes for things like icons, images…

By default core should only (at least for now) include all Dashicons like @senadir mentioned.

like @hacknug mentionned, devs in a design project situation would need the possibility to define their own set of icons from theme/plugin so that they can give their end users a limited list of icons to choose from.

Some WP use cases could maybe appreciate the possibility to have 7000 icons to choose from but sometimes less is better. In design projects where design tokens are predefined, icons are one of the elements editors have to choose from a list provided by design side of the project

[Sirjazzfeetz]

Words, words, words.. ~4 years worth 🤯 Time for IconPress!

Seriously though, took a while just to read up! Why not take a more agile and less abstract approach.. put a test version out ASAP, embrace community criticism as a valuable resource and refine through feedback. Then everybody will be on the same page, instantly, so we can collaborate, and include the wider non-coder community to vote on the process, have them rate the user experience (UX). It's difficult to learn by simply reading and writing, we need direct experience and experimentation.

Afterall, the compressed image of the icon is an inclusive and simultaneous form. Let's not exclude 50% of the world market; places like the United States, where the Graphic Revolution happened decades ago. The private point-of-view has long been replaced with group icons, private ideals with corporate images. All corporate logos are iconic because corporate awareness is iconic. Advertising is iconography, and only works on a literate audience which is uneducated and ignorant of iconic forms.

303 Dashicons, or dashboard icons, is not "impressive!", as one dev mentioned. No person from the East would ever say that. For example, there are 55,000 Chinese logograms, and probably more emoji's than that used by youth in the West. And the lack of dashicon quantity is certainly not made up for by their superior quality. 'SVG's are a security risk'.. even more than the WP ecosystem already is? There are ways to minimize such risk, already plugins, trust systems and tamper proof hash chains.

TLDR: let's not make this thread 5 years long before graphics are embraced to a reasonable standard.

[draganescu]

Since uploading SVGs is something that is probably not going to happen anytime soon, for valid reasons, I want to propose that the icon block does not provide any or, a very minimal set, of icons, but instead the addition of the icon block plus some api as #51563 alludes, would allow plugins to provide icon packs.

Thus the icon block becomes a display mechanism and plugins a source of reliable and save iconography for any sort of graphic need.

[mtias]

Everyone recognizes the value of icons and graphics for building websites. Given it's challenging to include any specific set in core, the discussion on this block should focus on the mechanisms, features, and infrastructure that an icons block in core might provide. Since this is very abstract and likely unhelpful, it might be useful to get something started as a separate plugin that can be iterated faster until good solutions emerge.

To clarify: it's challenging to add any specific set in core because it means maintaining them without major visual changes virtually forever to avoid modifying the appearance of people's websites. So it makes a lot more sense to leave that part open to the extensibility mechanisms of the platform.

[audunmb]

There is already an Icon block, it's called Social Icons, but it is limited. Though, it is really a Row block.

Making Social Icons into Pattern, with a Row block of Icon blocks, would make more sense within the block editor framework than having dedicated Social Icons block.

[Julianoe]

The current way the Social Icons is made does not bother me. It caters to a very very recurrent usecase. But that does not solve the question that you can't add custom icons/SVGs to the block editor without relying on plugins and quite a bit of custom code.

[zcraber]

Iconify by @cyberalien would be a great choice for icon framework. Over 150 icon sets and 200k icons!
https://github.com/iconify/iconify

[ajitbohra]

My favorite is "The Icon Block" by @ndiego from code to how it integrates with the block editor is seamless.

https://wordpress.org/plugins/icon-block/
https://github.com/ndiego/icon-block

also, allows registering custom icons https://nickdiego.com/adding-custom-icons-to-the-icon-block/