Proposal: add icons to the XWiki Icon Set

Hello! When updating some bits of UI in xwiki-platform, I happened to run multiple times in the same problem: the current XWiki Icon Set does not have the icon I want.
I compiled the instances where I ran in this issue in the past months. Here is my main proposal:

Add 8 icons to the XWiki Icon set. Those icons are defined on Add icons to the XWiki Icon Set (Proposal.AddiconstotheXWikiIconSet) - XWiki. Here is the mapping:

The reasons I want to add those icons are on the design page mentionned above. The mapping in itself is not perfect but that’s the closest I could get with the limited icons in the different themes.

This proposal is very similar to this proposal by @surli .

I think we should also rephrase the only link pointing to this page from the icon theme documentation :

The current list of available icons in Icon Themes is there as a draft.

This unique link does not reflect enough the importance that this list has in actually using icons when developing interfaces from experience, it’s difficult to find it when new to the project. I think we should update it to

The list of icon names available in the default XWiki Icon Set.

AFAICS, this list is pretty stable and important for our design, and the design page itself is not a draft anymore, so it doesn’t make sense to label it as a draft anymore.

Do you agree with those icon additions? Do you have an idea on how we could emphasize the importance of this list in the doc?

Lucas C.

IMO we should now just move the list from the design page to the doc.

1 Like

Thanks Lucas for proposing this.

I have some remarks/questions:

  • I think we need some consistency in the names. For example caret-left and move do not look consistent. Move is quite generic and could be about lots of things (moving a page to another location for example). What about prefixing all “arrow” operations with arrow to indicate there’s a notion of arrow in the icon?
  • The icon for move seems weird for silk as it’s a left arrow.
  • The icon for resize-horizontal seems weird for silk as I don’t see what’s horizontal in the chosen icon
  • 2 icon names don’t have a mapping for some icon themes and I think we need the mapping to be complete as otherwise it won’t work.


Thanks for your feedback!

I don’t agree with this fix, because I think a strength of the icon set is the easiness of the names. Systematically adding prefixes will make using this feature more difficult than it needs to be. AFAIK we don’t have specific icons for moving pages or moving attachments in the iconset so this lack of specificity is not an issue. I agree that caret-left and move have different naming conventions (based on the character vs based on semantics), but it’s something that’s already in the iconset with ‘add’ and ‘caret-right’ for example. I don’t think this is much trouble for devs so I’m in favor of keeping things the same.

Unfortunately, silk was created in 2005 and not updated for a long time, so there’s some huge holes in its icon theme cover. When checking out a list of the icons in silk, I could not find anything closer to those we would expect for those actions.
I think it’s more important to have an icon set that can represent a variety of icons, even if silk is a bit left behind. If we don’t provide enough icons in the set, devs will need to:

It’d be nice to find a better mapping for those, any suggestion is welcome :slight_smile: .

AFAICS a lot of icons in the set are in the same situation as of now (see the icon set definition). I thought this would be okay.
I don’t mind too much leaving the bell icons for a later update because the only theme where these variations really make sense is FA, and we’re still lacking one icon for the full UI revamp proposed in Notifications - Watch buttons (Proposal.Notificationwatchbuttons) - XWiki / Complete redesign of notification watch buttons - #16 by tkrieck .

Regarding silk shouldn’t we just start deprecating it? As you said it’s starting to get old, and I think we’re all more relying on FA those days than on silk. IMO it would make sense to deprecate it and stop bundling it in the future, maybe when we move to 16.x or 17.x.


  • I prefer Silk’s arrow_out for move, even if it’s used already for arrows in the icon set.
  • We already have plus-square and minus-square in the icon set. I don’t see the need for plus and minus.


I agree to eventually deprecate it. However for now silk icons are still used in a few places that we need to update. XWIKI-10755: Replace Silk icons references with IconThemes values


You’re right, I did only check the documentation page, which was out of date, but the mappings in FontAwesome.xml and Silk.xml do have values that are not mentionned here…
I’ll move this list to the icon theme documentation and update it so that it fits what we currently have.

Thanks for your feedback! :slight_smile:

1 Like

The point is that the name should be about what the icon represents and not about a concept since otherwise 1) we’ll have namespace problems and 2) different icons can be used for the same concept (e.g. use one icon for “move page” and another icon for “move attachment” or “move a panel”).

I didn’t say that we shouldn’t add these icons but we need an acceptable mapping for the other icon sets. This is crucial as otherwise the whole concept of icon set goes away (if you can only use a single icon theme).

Well, it means we would not be able to use the Elusive icon set. If we don’t want to support it, then we shouldn’t list it. However, I think it’s a good idea to list it and to perform the mapping as it offers a proof that the new icons can have mappings in several icon sets and that’s important. So yes IMO we do need to make the effort of providing mappings for all icon sets, just as a proof that we can find mappings and thus that we are not adding an icon that is too specific to one icon set.

This was not my point. My point was that we need a mapping for the bell icons, for all icon sets.

Sounds good generally speaking, but could you explain precisely what you mean by deprecating? I think we need to make sure that contrib extensions (or custom code) continue to work if they use Silk. Does deprecating mean that when using Silk in future XWiki versions, the UI would get broken? IMO, one simple solution that could be acceptable would be that each icon set could provide a default icon when no mapping exists for a specific name. That would allow Silk to continue “working” (even if it would be with icons not nice) in the future, at a low cost.