color not embedded in icons

[aspiers]

Kind of issue

• Improvement
• Bug
• Other, namely:

This issue concerns

• The NPM Package
• The website
• Other, namely:

Description

This is a great resource / website, and it's cool how the color of each icon is explicitly listed as metadata. However I don't understand why each SVG available for download is monochrome. I'm quite sure this was a deliberate design decision, but it makes it impossible to download an SVG and instantly import it into (say) an image/video editor and have it immediately be the right color. An extra step is required to apply the color, and I'm confused why this extra work is being required. I understand the need to avoid duplication of color values between each SVG and simple-icons.json, but surely the website could offer the option to download both monochrome and color versions?

Or even if that's not possible, it would be good to at least document some quick techniques for applying the colors to obtain a colored version of the SVG. For example:

sed 's/<path /<path stroke="#ff0000" fill="#ff0000" /' \
    youtube.svg > youtube-red.svg

[ericcornelissen]

The primary reason the color is not included in the SVG is because not everyone wants to use the icon with that color. Although it may be common to use the icon in the specified color, other options (specifically #000000, #FFFFFF and grays) are also common.

Although we do not explicitly state the icons are monochrome, that is more or less the service we provide: monochrome version of brand logos. With regards to importing the icons into an image/video editor I would say that this is (at least currently) not our main focus, we focus mostly on web development (where styling should be done through CSS).

With regards to documenting techniques for applying colors, this would be an interesting challenge. As I said before in web development this should be done through CSS. Otherwise the most straightforward way is to just update the SVG which is a pain to do manually. A tool like IconJar (see also #975) might help, but it is only available on MacOS. Another option would be to let user specify the color before downloading the icon as e.g. FlatIcon does, but the drawback here is that it now takes two clicks to download an icon...

In conclusion, I think we can and should look into this, especially with the redesign (#980) in mind. However, I hope you understand why we do things the way we do and that it might take a while to get your feature request out there 🙂

[aspiers]

@ericcornelissen commented on 6 Nov 2018, 15:01 GMT:

The primary reason the color is not included in the SVG is because not everyone wants to use the icon with that color. Although it may be common to use the icon in the specified color, other options (specifically #000000, #FFFFFF and grays) are also common.

Sure, that makes perfect sense.

Although we do not explicitly state the icons are monochrome, that is more or less the service we provide: monochrome version of brand logos.

Well, you also provide the color hex codes :-) And since you have both, it seems like an obvious enhancement to offer the combination as an extra option :-)

With regards to importing the icons into an image/video editor I would say that this is (at least currently) not our main focus, we focus mostly on web development (where styling should be done through CSS).

Yeah I get that, but the icons are so good that it seems a shame not to also provide color versions, assuming that this can be done without too much extra work.

With regards to documenting techniques for applying colors, this would be an interesting challenge. As I said before in web development this should be done through CSS. Otherwise the most straightforward way is to just update the SVG which is a pain to do manually.

It's not too hard - e.g. see the sed command I suggested above :-)

A tool like IconJar (see also #975) might help, but it is only available on MacOS.

I think that's fine - it seems perfectly acceptable to me to document several different ways of achieving the same thing.

Another option would be to let user specify the color before downloading the icon as e.g. FlatIcon does, but the drawback here is that it now takes two clicks to download an icon...

It wouldn't have to take two clicks. You could have an extra link for downloading the color version, without changing the existing behaviour of clicking on the icon.

In conclusion, I think we can and should look into this, especially with the redesign (#980) in mind. However, I hope you understand why we do things the way we do and that it might take a while to get your feature request out there 🙂

That's great - thanks very much for the consideration! And of course I understand that it won't happen overnight ;-)

[ericcornelissen]

Yeah I get that, but the icons are so good that it seems a shame not to also provide color versions, assuming that this can be done without too much extra work.

First off, thanks for the kind words 😊 Second, I agree. The reason I stated we currently focus on web development is, well, because that is the case. I'm not saying we won't support other usages of the icons, but so far the demand just hasn't been there (apart from a couple of issues, #743 comes to mind).

Also we're operating completely open source and have no incentives to reach a broader audience. Even though me and @birjolaxew do most of the work around here, we do not actually own the project. So it is unlikely new features will be added unless we ourselves want them, or the community requests them.

It's not too hard - e.g. see the sed command I suggested above :-)

However, not all icons are equal. Most icons would probably require fill to be set but maybe not all of them. On the other hand, we currently assume no strokes on icons, but maybe some icons will benefit from a stroke rather then a fill... And there's probably more to think about 😅

I think that's fine - it seems perfectly acceptable to me to document several different ways of achieving the same thing.

I'm not opposed to that either, I'm just pointing out the pros and cons.

It wouldn't have to take two clicks. You could have an extra link for downloading the color version, without changing the existing behaviour of clicking on the icon.

That is a fair point, and also why I referred to the redesign effort 👍

[birjj]

This is an interesting topic.

It is correct that with the current approach, controlling the color through CSS is easier. However this is generally a bit difficult (namely you can only do it if the SVG is embedded directly onto the page), and in those cases it is trivial to either remove the fill from the code or overwrite it in CSS. In short, while the current approach is generally what people want, it does make some use cases harder than necesarry.

As for embedding the color directly in the SVG, that also has some problems (mostly related to how the current icons are used). People using our icons through a CDN targetted at @latest will have their site designs break, and having to overwrite the color in CSS will be a (minor) friction point for those who just want monochrome icons; I believe this is the majority of our users (although I have no data to back that up). It would obviously be a major breaking change, and should therefore be bundled with other major breaking changes (namely #770).

Personally I've been playing with the thought of providing two variants of each icon: a full color and a monochrome one. This would be a massive amount of work to find full color versions of all existing icons, but would allow us to support e.g. #788, while also expanding what the icons can be used for.

[aspiers]

Thanks a lot for your thoughts on this so far, guys!

@birjolaxew commented on 6 Nov 2018, 16:46 GMT:

As for embedding the color directly in the SVG, that also has some problems (mostly related to how the current icons are used). People using our icons through a CDN targetted at @latest will have their site designs break, and having to overwrite the color in CSS will be a (minor) friction point for those who just want monochrome icons; I believe this is the majority of our users (although I have no data to back that up). It would obviously be a major breaking change, and should therefore be bundled with other major breaking changes (namely #770).

To be clear, I wasn't meaning to propose any breaking change like introducing colour to existing icons.

Personally I've been playing with the thought of providing two variants of each icon: a full color and a monochrome one.

Yes, this makes much more sense to me.

This would be a massive amount of work to find full color versions of all existing icons

I wasn't proposing that either ;-) But merely to dynamically apply the single colour in the .json file to the existing monochrome images, and offer those as an extra download.

Having said that, it might be problematic with images which naturally use multiple colours (rather than just a single colour, or shades thereof), as you have already observed:

but would allow us to support e.g. #788, while also expanding what the icons can be used for.

Yeah, that's a good point. But wouldn't simply retrofitting the single colour to existing monochrome icons be a decent start at least?

[davidklebanoff]

It is important to note that the color we provide for a brand is the brand's primary color, which is not always the same as the color of a brand's icon or logo; and as mentioned, multi-colored logos present a whole set of challenges as well. Put simply, we don't currently have the data to do this correctly.

I agree with @birjolaxew in that I think the correct solution is to have full-colored versions of the logos, but as he also mentioned, it would be a huge undertaking.

I don't see us having the bandwidth for such a tremendous task at this time, but maybe you guys are more optimistic. :)

[cyberalien]

It is correct that with the current approach, controlling the color through CSS is easier. However this is generally a bit difficult (namely you can only do it if the SVG is embedded directly onto the page), and in those cases it is trivial to either remove the fill from the code or overwrite it in CSS. In short, while the current approach is generally what people want, it does make some use cases harder than necesarry.

Try this jsfiddle. Its a fork of your code with added Iconify code at bottom of page. It might be solution you are looking for.

I can write long description of what's going on there, but that would be long and might sound like I'm spamming my own project. It an open source SVG framework and it supports Simple Icons. Result is same as embedding SVG, but without including SVG code on every page.

[ericcornelissen]

That is an interesting solution @cyberalien, however I can image not everyone would want to use Iconify (or any JS at all for that matter) when using icons from SimpleIcons.

Also, your jsfiddle doesn't work in Firefox 🙃

[cyberalien]

Weird, works fine in Firefox for me. Could be a bug somewhere. Can you please check browser errors?

[ericcornelissen]

@cyberalien I'm gettings these errors ⬇️ in FireFox Quantum 63.0.3 (64-bit). Seems like an issue with iconify?

SecurityError: The operation is insecure. iconify.min.js:13
TypeError: i.scanDOM is not a function[Learn More] iconify.min.js:13:1438

[cyberalien]

Thanks a lot, that is very helpful! I'm not seeing such error on same version of Firefox on any computer, but at least now I have something to investigate. Thanks!

[thibaultmol]

Q: isn't possible to just have a .zip file for each release that contains all the icons as colored svg's? (or png's)

[runxel]

Hey @thibaultmol
A: This could be possible indeed. 🤔
We actually have an action that converts all icons into PDFs. I suppose we could alter that scope to include the color; from my point of view there is no point in having the PDFs to be colorless ("black") as well.
Pinging @ericcornelissen, he has a bit more knowledge there.

[ericcornelissen]

tl;dr: it would definitely be possible, but from my point of view that shouldn't be the priority of the maintainers at the moment.

We actually have an action that converts all icons into PDFs. I suppose we could alter that scope to include the color; from my point of view there is no point in having the PDFs to be colorless ("black") as well.

That is indeed correct (though the bot doing that for us has been experiencing some difficulties lately and given that there has been no demand for the PDFs I haven't looked into fixing it). One could definitely use a very similar bot to create colored SVGs and/or (colored or not colored) PNGs.

That said, other means of automation should also be possible. E.g. a repository that uses RenovateBot or Dependabot to update the simple-icons dependency and uses a CI pipeline to convert them in whichever way one wants.

In any case, I would personally be inclined to separate that project from this repository (in the spirit of separating concerns).

However, given the current struggle the project faces regarding keeping up with icon contributions I don't think this is an opportune time for us to work on a feature like this.

Of course, @thibaultmol, you are always open to set up a project yourself that converts the icons. It should be fairly straightforward to automate this using the NPM package (relevant docs) and I think we would be happy to list it as a Third Party extension. If you have any questions regarding that you are free to ask us for help.

[jorgeamadosoria]

this issue's discussion seems to have run its course. Shouldn't we close this now? @ericcornelissen ?
The issue in the website for adding color is follow up enough, I think.

[ericcornelissen]

Yes, let's close due to it being stale