The Seven Style Guide used a commercial icon font as a placeholder in its design. There seem to be no GPL-compatible icon fonts out there. So I made one:


Current implementation

SVG that falls back to PNG via Modernizr.
The SVGs were taken from the Libricon repo and renamed to remove the numbers.
The SVGs were edited in a text editor to modify their fill colours and placed in misc/icons/#hexcolor.
Grumpicon was used to batch convert all SVGs to PNGs.
The images are referenced in CSS files like so:

.toolbar-bar .toolbar-icon-home:before {
  background-image: url("../../../misc/icons/bebebe/house.svg");
.no-svg .toolbar-bar .toolbar-icon-home:before {
  background-image: url("../../../misc/icons/bebebe/house.png");

The .no-svg class is added by Modernizr, be sure to attach the Modernizr library to the elements that use the icons.

Related issues - #styleguide-add-icons

#1963886: Use HiDPI icons in the toolbar
#2022695: Content header style update
#2075949: Add Libricons to messages
#2016875: Admin navigation list style update
#2083945: dblog.module: Update use of icons
#2083947: system.module: Update use of icons to new standards
#2083949: filter.module: Update use of icons to new standards

Consider using a font icon instead of SVG

- Evaluate the design and implementation technicalities of using a webfont for core icons.
- Determine how contributors can work work with this technology.
- Make a patch to add the font as a library
- Make a patch to use the font

#28 Acquicons_ai.zip1.07 MBtkoleary
#27 Screen Shot 2013-07-25 at 10.25.44 AM.png44.62 KBtkoleary
#22 2032773-libricons-22.patch135.74 KBLewisNyman
#14 2032773-libricons-14.patch42.01 KBLewisNyman
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 2032773-libricons-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#10 libricons-grid.png59.15 KBry5n
#9 libricons.zip1.96 MBGaelan
libricons.png75.95 KBry5n


Title:[META] Use Libricons in Seven, consider using it more broadly in coreUse Libricons (icon font) in Seven, consider using it more broadly in core
Status:Needs work» Active
Issue tags:-icons, -styleguide-add-icons+styleguide-independent

Looks nice, though we might be able to use if we get an SIL exception for Source Sans. Also, the use of the < i> tag for icons bugs me. Could we use a < span> or even just allow an icon to be prepended to any element?

Issue summary:View changes

More issues

I'm kind of doubting a license exception is going to be the way forward for Source Sans. It's assigned to Dries now so that he can decide which direction we're going to go. However, I'm very much in favor of using a homegrown font for our icons. Avoids license issues, we can include exactly what we want, and if changes need to happen, we can bribe ry5n :P

Yeah, I doubt we'll get an SIL exception either. I think Libricons looks great, I was just putting the suggestion out there.

I no longer believe we should chase Source Sans, but that’s another issue. As for the markup, the font and the CSS will work with any element; if folks object to the <i> tag, I completely understand; in that case we can use <span>.

I will accept bribes (JK), but actually the github repo linked in the summary has full instructions on generating updated font files from source SVGs, so everyone can contribute.

@ry5n awesome work. I am totally behind implementing this in core right away.

@tkoleary Thanks. I’m going to encourage other folks to take this the rest of the way. If it gets in, I will of course help maintain it.


Could this get a picture of all the icons + a designer friendly source file (e.g. the AI or PSD).

Assigned:Unassigned» Gaelan

Generating AI files.

Assigned:Gaelan» Unassigned
new1.96 MB

Done. This zip has both the SVG and AI files.

new59.15 KB

Updated image in the summary to show all icons. I am happy to make more as needed; just let me know.

BTW, per point two in the Remaining Tasks, I documented how anyone can contribute on the GitHub project page:

Awesome, thanks guys!

@r5yn While you are at it, in your break. Can't you make a font too? :P

It looks like this is missing styling for error, success and warning messaging. Those do need to use color. We are also missing - resizing of a textarea icon, question mark icon and what about file types? I know we are using some of those icons in the file upload field.

Issue tags:+CSS

Great stuff Ry5n, we needed someone to step up and you did :-) Let's start with Seven, I'm mindful that many other admin themes have their own icon sets. There is no reason why we can't start patching this in now right?

I'm so excited! I'll work on a patch on the way home today.

Status:Active» Needs review
Issue tags:-CSS
new42.01 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 2032773-libricons-14.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Never mind couldn't wait. Here's my patch proposal:

  • We add libricons as part of Seven
  • In follow up issues we add the classes to the core modules to leverage these icons.

I've made the output CSS more generic, changing the class .iconset-libricon to simply .icon. This would allow other admin themes to receive the same semantics from the core/contrib module but replace the implementation with a different icon set.

The only remaining question mark would be messages, because they get displayed across all themes.

Status:Needs review» Needs work

The last submitted patch, 2032773-libricons-14.patch, failed testing.

This is an independent project, although I made the icons to cover what Drupal core needs. So my proposal is to include this as a library the same way as jQuery, Normalize, etc. It’s MIT licensed.

Although Drupal is free to include the library but use its own CSS, I don’t think the class setup in #14 is a good idea. This CSS will be loaded alongside every public theme, which may have its own icons/icon CSS. I thought long and hard about how to avoid collisions with other themes and stylesheets, and also provide extensibility. So for example, the standard pattern used by many of the icon font vendors is:

[class*=" libricons-"] {
  font-family: 'libricons';
.libricons-home:before {
  content: '\e000';

This is nice because the markup is shorter: <span class="libricons-home"></span>. However, if I needed a variant of the base style, say to adjust alignment with lowercase type, I would have to do something like .libricons--lowercase but that’s wrong because there is no base class (.libricons) present. If I instead use .libricons-lowercase then that’s indistinguishable from the class you’d use for an icon called “lowercase”. Also, regex selectors are relatively slow.

With the current Libricons CSS, you can do <i class="iconset-libricons .iconset-libricons--lower .icon-home"></i> with no ambiguity. The downside is it’s verbose and a little bit unconventional. I kind of don’t like it myself, but it’s the most flexible way I’ve come up with so far. If anyone has an idea of how to do the CSS better – and still meet all of the requirements – I’m all ears.

As for contributing, the instructions are up on the github repo. The workflow would be to fork the repo, make changes and open a pull request. Then the updated library would get merged into Drupal through the issue queue. The reason for this is that I want this icon set to be available to *any* project that is saddled with a restrictive license like the GPL, not just Drupal.

One final note: before I made these, I did a thorough survey of core. AFAIK, every icon currently in use has coverage here. Colors, sizing etc. is not the job of the library: that would be up to the theme.

But if we use a libraricons specific classes, it means the other admin themes with their own icon fonts can't really use those classes. I understand the need to keep them admin specific. How about a .drupal-icon class or something similar?

@LewisNyman Classes can’t be re-usable because available icons, icon class names, mapping of classes to unicode code points and even what glyph exists at a given code point can all vary between icon fonts. This all means is that each icon font needs its own unique stylesheet, and its own specific classes that won’t conflict with another one.

Although ideally themes will stick with a single icon font, it’s actually easier to mix and match icons if the icon classes are unique.

#14/#16: I'm afraid even all that is oversimplification. I do think it would be okay for a specific theme to use an icon font being overrideable on its own, but it's *not* okay for modules to start assuming the theme will provide icons.

Please see #1963886-55: Use HiDPI icons in the toolbar for more details on this rather thorny problem.

@Wim I’ve skimmed that issue; there are indeed some serious challenges if we want the icon set to be extensible by contrib. I will need to look more closely. In the meantime, let me just be very clear that my idea is that this icon font be available as a library (registered by system module?), so it would not be provided by a particular theme. Any theme or module could include it using drupal_add_library or drupal_add_css.

I am happy to discuss this more but I do not think we should be pursuing font-icons in this issue, we should add icons to core that we can use tomorrow. Anything that keeps us from doing that should be treated as follow up, its cleary that font-icons needs a lot more discussion to get it right. We should be able to get SVG icons in quickly, so lets do that.

new135.74 KB

With that in mind here's a patch that adds the icons, with an example implementation for messages. Here's a question that quickly came up, if we're including the icons as a third party library, how do we handle colour changes for svgs?

This is the main reason I don’t like SVG. AFAIK, you need one file per color: no way to change the icon color from an external stylesheet.

Here’s my advice: use the Libricons icon font in core, not SVG. For contrib, provide advice on how to make their own icon font or SVG. If it’s only one or a few icons and they opt for icon font, they can use the Icomoon web app to generate a stylesheet with their icon(s) base-64 encoded right into the stylesheet using data-URIs, so just a single HTTP request.

AFAIK, you need one file per color: no way to change the icon color from an external stylesheet.

Nope (but you might need to use svg inline. But guess what. No IE8

@nod_ That’s right. I should have said there is no easy way. The only way to apply theme CSS to SVG is to include the raw SVG in HTML, which may be awkward. You can use an external stylesheet with SVG as an <object>, but it has its own drawbacks. A comprehensive guide is here:

Again, this is why I personally find icon fonts to be the most flexible solution at this point in time.

If I can add a class to a menu item, I can do pretty much what I want with icons as a themer. If I can add an i or span element to a menu item I can address accessibility issues as well. That's pretty much the way people do it on their own now. If those were available in core I could override at will. Where do I keep my icon font/svg/image? My theme knows. How do I change them? I change my theme. How do I override icons in core themes? How do we override anything in core themes now?
Not all menus are constructed thru the menu administrative interface. For example the toolbar is really a composite menu built from the toolbar, user, shortcut, and contextual modules. So there isn't one place to solve this. Though I think it would be good to have a well known and widely used 'Drupal standard" icon set, I also think it might be better to change core to facilitate icons than attacking it one menu or theme at a time.

But, if that isn't acceptable, a lot of extendability can be added thru config files.

ps. I think having icons on toolbar sub menus make them look more modern.


I am working on an extended set for Ember and Acquia distros that builds off of Libricons with some subtle stylistic differences (more geometric). This set comes closer to covering every icon used throughout core adding icons from edit, responsive preview, etc. as well as most icons for wysiwyg if a theme wants to re-skin it (we may do this in Ember).

Feel free to use these as is or alter them to stylistically match your set. There's no license yet but they will be GPL when the set is complete and I make it into a font. Also the social row is not by me, it comes from font awesome which is also GPL.


new1.07 MB


Here's the illustrator file. Make sure to replace the underscore with a dot after uncompressing.

@tkoleary Thanks! I appreciate it. We can absolutely look at merging the sets for Drupal core; however I’m determined to keep Libricons itself licensed under MIT, so I won’t be able to incorporate Aquicons into the Libricons project proper.

Speaking of licensing, I did a double-take when you mentioned that Fontawesome is GPL, since the whole reason I made Libricons was because I could find no font icon set that had a GPL-compatible license, including Fontawesome. So I checked, and it’s true: the Fontawesome code is MIT, but the fonts themselves use OFL SIL, which is not GPL-compatible. Therefore I am not sure if you can use those icons if Acquicons becomes GPL.


I have not GLPed the icons yet and I'm still working on them so at this point you can just use them as scratch artwork to modify and adapt to your libricon style (apart from the social row second from the bottom, which are font awesome).

Thanks for the info on font awesome. I will make my own social set and remove them.

So, I'm going to use the SVG files in this repo ( for the icons in #1963886: Use HiDPI icons in the toolbar. Any objections or licensing concerns?

So, in order for me to use these icons, I'm going to need light versions, too (for darker backgrounds).

Thinking forward, I believe we could get icon fonts working in contrib. We would knock out the module.icons.css files, inject the libricons classes on the appropriate links, and style them with the icon font.

For now, just using the icons as background images will at least make the icons in core scale.

@jessebeach Go for it! BTW I am fine with Drupal choosing a different CSS implementation than in the library. The source, code and fonts are all MIT, so all that’s needed is that the license accompany whatever version is included in core.

Just FYI, there is one way to do SVGs so they can be styled using external CSS: inline the SVG itself into the HTML. Then you can do stuff like .icon-blah path { fill: #fff; } but I don’t know how folks feel about raw SVG data mixed with markup. Would need theme functions or something, and this approach makes caching difficult, but it provides a similar degree of CSS control to icon fonts.

Issue tags:+icons

@jessebeach In regards to the theme template (formally a function), see #1849712: Add theming template and prepare logic for rendering icons also. Take note of the issue blocks in the summary. I'm currently working on them, but seeing how it's code freeze.. idk. Wish we could extend that like we did feature freeze, soo much still left to do. For now, I think we might just have to use manual markup :(

As per #34, I agree. Manual markup is going to be most practical.

@Mark Carver and @ry5n, at this point in the release cycle, we're not going to get icon fonts introduced to D8. We're left with a minimally invasive intervention to improve the scalability of icons, which means SVGs as background images. So given that, we'll need a light-colored set and a dark-colored set. I can attempt to make that set, but that involves me setting up a tool chain. I'd really appreciate it if folks with that tool chain already set up could produce a light-colored version of the icons :)

@jessebeach I don't think the actual icons themselves will get in, no. I was just referring to having a "standardized" template for outputting an icon via the theme system (whatever you use: font, sprite, svg). That being said.... :)

#1751194: Introduce hook_theme_suggestions[_HOOK]() and hook_theme_suggestions[_HOOK]_alter() was just approved!! It was semi-blocking #2035055: Introduce hook_theme_prepare[_alter]() and remove hook_preprocess_HOOK(), which would finally allow me to get #1849712: Add theming template and prepare logic for rendering icons implemented properly so you could so something like:

return render(array(
  '#theme' => 'icon__svg',
  '#path' => '/arrow.svg',

Which would probably output something like:

That issue dependency chain strikes me as risky. @Mark Carver, what's your opinion of the temperature of the community on an icon font? Is this something that still needs to evangelized? Or is the issue chain a straight-forward block of work to be completed without controversy?

Honestly, there's fiery debates about how icons should be "implemented" and "which kinds" should be used. Personally, I prefer font based icons since you can do more with them (via CSS). But we're a long ways off from actually implementing a "core" icon set. Right now, I'm just mainly concerned with how we add icons (of any type) via Drupal. Mainly so we can construct the proper markup (with appropriate classes so things like screen readers will ignoring them and we can target them accordingly).

That issue dependency chain strikes me as risky.

FWIW, the first two issues were just approved so they'll be committed soon. #1849712: Add theming template and prepare logic for rendering icons is only an addition (ie: we've never had an icon theme function/template)... so I can actually see this getting in before release eventually.

Also to clarify, I'm not trying to hi-jack this issue. Feel free to use whatever you deem is appropriate for now, just wanted to let you know about that one issue and where it's headed (eventually). Might wanna put in some @todos with links to it.

I think the main problem with icon fonts is that they go in the face of Drupal's flexibility. In Drupal, all kinds of modules may add new controls and options or alter existing ones. If they also want to use icon fonts (and a suitable icon is not available in core), they need to create yet another font. And yet another for another module, etc. That quickly ends up with several fonts loaded and being used just for some icons. Not sure the elegance / performance improvement of iconfonts still stands in that scenario. You'd end up loading a base font for icons some of which you don't use and load more fonts for overrides and additions.

So not knowing about this issue I did some mockups + new icons for the toolbar at #1849086: Styling changes to toolbar ICONS.

Direct link to mockup.

I agree with Gábor that font icons will add more complexity. In terms of load time, 1 sprite PNG VS font file + library + other font icons?

Btw I would love to hep continue to work on designing the icons in any format preferable.

@Mark Carver: re #42 so long as none of the optimisations / font regeneration, etc. is done in core, it sounds to me like a sub-optimal solution for core. Saying any module that needs to extend the toolbar needs to add a dependency for one or more of these modules in contrib to be optimized sounds like a problem to me :/

I'll shut up after this. I think my presence is just confusing people.

@Gábor: I'm not proposing contrib should be used to support core (those modules are just a proof of concept). I'm only suggesting we add a "standard" icon template that should be _extensible_ by contrib, not locked down by core (like other theming functions/templates have been in the past). See the issue I linked in #39.

Title:Use Libricons (icon font) in Seven, consider using it more broadly in core[META] Use Libricons in Seven, consider using it more broadly in core
Issue tags:-styleguide-independent+styleguide-add-icons

#1963886: Use HiDPI icons in the toolbar has landed, which I think makes this issue a meta. I'm going to create/tag issues that need SVG libricons added. We can use this issue to track them and decide on high level implementation. I'll update the summary as soon as I can.

Issue summary:View changes

Replace summary image with grid of all icons

Issue summary:View changes

Added instructions and references to SVG implementation issues

To be replaced:

Contextual links
Dropdowns (e.g. fieldset)
Drag and drop icon
Lock icons in theme color settings

Issue summary:View changes

Added messages issue

Issue summary:View changes

adding 2016875 to styleguide-add-icons

@r5yn Could you add a throbber?

I'd rather open a separate issue to redesign the throbber. There are several design problems with the current one that a new icon won't solve. For example: #1847916: Replace the ajax-progress-throbber div with a class We also have some UI fragmentation (see Views) and lack of documentation on when to use each one.

Also, the throbber needs to be animated (which affects implementation), so it does merit its own issue. And just a reminder that the Style guide does include a design for one.

The toolbar looks absolutely lovely with those icons. Awesome work. Hope the implemenation differences can be sorted out, can't wait to see this in.

In the small size, it gets clear that the puzzle icon could be a little clearer (make it less rounded so the holes and things that go into them stand out more) and the newspaper icon for content could have thicker and maybe fewer lines for the text.

Don't we also need all file types?

Status:Active» Needs work

We will also need icons for all potential wysiwyg buttons.