Gitlab Icon project/website integrated into the existing gitlab ce/ee projects

Issue idea came from: https://gitlab.slack.com/archives/C03MSG8B7/p1490797179681755

Usecase

We want to get rid of fontawesome's iconfont and convert fully to using svg's. Also we want our icons to be more standardised and control their quality, optimisation and unified look.

@jschatz1 do we want our icons to be webpack loaded as mentioned here?

Problem

Our current usage of icons is mixed between svg's svg.erb's and fontawesome icon font.

We are more and more in need of custom icons and they still need to make sense as a whole (they should look like they are of one and the same icon family so to say, because this creates a better unifiquation throughout the interface and makes it looks more aesthetically pleasing)

Proposal

• extend =customicon to be able to have size and class as inputs (similar as =icon with fontawesome's icons helper function has)
• create an icon website out of shared/icons similar to https://octicons.github.com/
  • the idea here is that the icon website always correctly represents the icons being used within the application. Also any icon in the website is already available within the application this way.
  • perhaps let this be its own project and loaded into the current project as a submodule?
• setup some ci tests on those icons, so we can only accept icons which are properly optimised and have correct sizes etc

Ultimately this means that if a developer needs an icon, which is not yet there. They can ask a designer to create a separate merge request if needed in which they provide and merge the icon.

Value

• Controlled, unified and verified icon usage
• Clear communication on icons with website, which may perhaps benefit help documentation as well
• There is one true source of icons
• If this is in, we can move to remove font-awesome's icon font!!

Related issues

https://gitlab.com/gitlab-org/gitlab-design/issues/18

CC/Call to actions

@jschatz1 @annabeldunstone (you were part of the discussion .. how can we make this possible? I would like to set this up, but need to know how)

mentioned in issue gitlab-design#18 (closed)

cc: @hazelyang (we talked about it )

@jschatz1 @annabeldunstone any idea how to make this a reality?

mentioned in issue gitlab-foss#14420 (moved)

cc: @timzallmann This issue is related to our discussion on how we handle icons, looping you in.

@dimitrieh Take a look at http://fontastic.me/ (I am not sure if it is discontinued cause there were no updates for a long time) Nice thing is the actual management of the icon set. We can also setup an automatic workflow without such a tool to bundle them automatically. @sarrahvesselov any opinion on single files/svg sprites ?

@timzallmann I am a HUGE fan of using svg sprites. You get beautiful crisp lines in any device, only one http request, can have multiple colors, and can generate a handy icon map to make it easier to find which icon you need. I am not sure about that link, I typically generate my own file svg's, clean them up a bit using this tool: https://jakearchibald.github.io/svgomg/, then create my svg sprite file. For reference @dimitrieh, this link goes over how I have set up my svg's in the past : https://css-tricks.com/svg-sprites-use-better-icon-fonts/

100% agree with using svg sprites and I've used the same process @sarrahvesselov linked.

@annabeldunstone I know we've discussed using svg sprites in the past, and that exact article. But I'm not sure it was ever implemented on the frontend side. What is frontend currently doing with the svgs?

They're currently being loaded directly as partials, using custom_icon.

Take a look at this article that talks about going through HTML, seeing which Font Awesome icons are used, and subsetting the font accordingly, which cuts the font size down enormously: https://pixelambacht.nl/2016/font-awesome-fixed/

We can either do something similar to that but for SVGs, or make the icon set maintenance a manual process of adding and removing Font Awesome icons.

Related to this issue

mentioned in issue gitlab-foss#32894 (closed)

marked this issue as related to gitlab-foss#36231 (closed)

marked this issue as related to gitlab-foss#32894 (closed)

moved from gitlab-foss#30254 (moved)