Is it possible to create 2 variants of the same icon?

[dzintars]

I have an geometric icon which in small scale (like in badges) does not look good in outlined variant on non-retina screens.
But the monochromatic outline variant is used in some of the official docs.
So, the solution would be to commit 2 variants:

• icon-name-outline
• icon-name-fill
  Is this acceptable or i should go with the officially used variant only?
  It's a OSS project.
  I made a poll in the "official" community and waiting for the votes to come in, but until that double variant case feels appealing to me as that would suite all use-cases.
  For the context there is an WIP:
  
  P.S. In the image filled icon lost few pixels of the height and the sizes of the booth icons are not the same. That will be fixed.

[PeterShaggyNoble]

Thanks for raising this for discussion, @dzintars 🙂

To provide a little bit of background on this: one of the limitations that prevented us from considering this in the past was having no way to differentiate between the variants. In the example you provided, both entries in the JSON would have had the title "Bazel" and both SVGs would have had to be named bazel.svg which, obviously, would have been an impossibility. However, with the recent addition of custom slugs, this can now be solved by adding a slug entry to the variant's JSON.

So the question then becomes: is this something we want to start supporting? After a little bit of thought, I think I'd be in favour of it, personally. There are cases, such as with Hackster where they provide different variants of their logo/icon for use in different situations (usually light vs. dark backgrounds) and we're left to make a judgement call on which to add, usually opting for the primary variant. This then means that if the situation a user is using the icon in differs from the one we chose, they are using it incorrectly and, depending on their wording, potentially in violation of that brand's guidelines. But I would say that we should only do it if there are variants that are made available officially by the brand itself.

I also think that, while we don't currently place any restrictions on what the modifier of a custom slug should be, other than it should be relevant to and descriptive of the brand, for variants we should require specific modifiers so as to be consistent. I would suggest that they should be *_outlined, *_filled and *_variant, the latter being reserved for rare cases where the brand provides a secondary icon that can't be differentiated as outlined vs. filled.

With regard to your specific example of Bazel, I think that's a discussion that needs to be had separately as it's a bit of an edge case where there is an official monochrome outlined version and no monochrome filled version, but the full colour filled version can be made monochrome through the addition of cut-outs, something we already allow for and have many examples of. So I suggest you proceed with the PR for the outlined version and, pending the outcome of this discussion, open a separate issue where we can discuss the filled version further. Of course, that would all be pending the outcome of the poll you mentioned in #5573.

[adamrusted]

Agreeing with @PeterShaggyNoble's comment above. I think we should always aim for the 'primary' to be just brand.svg - and the other variant being _filled.svg or _outlined.svg. As @ericcornelissen pointed out, that would mean that the updating of a brand must take effect across all variants in the same PR, which may not always be possible.

It might also be worth us looking to have a fail-safe whereby if a variant file isn't found, the API defaults to returning the base brand. That way, should a brand update their logo and only require a single variant, it's not considered a breaking change for us to 'remove' the variants.

[PeterShaggyNoble]

My suggestion would be that rather than creating a new entry in the JSON for the variant that we instead add a new, optional variant entry taking a value of "filled", "outlined" or "variant". This would avoid the implication that it's a separate brand and allow us to reserve those 3 modifiers by disallowing their use in the slug entry. They could then be implemented in the package through the addition of an options parameter to simpleIcons.Get() (which we've had brief discussion on elsewhere); Pass variant:true to the options parameter and it will return the relevant SVG if present, or the default if not. I don't know if we could do anything with the require statement, redirecting require('simple-icons/icons/brand_variant') to simple-icons/icons/brand if the variant doesn't exist. Of course, if people are using the SVG files directly then there's not much we can do there and the removal of a variant is still going to be a breaking change.

[adamrusted]

Passing via a optional options object could be pretty good, and could open up some interesting opportunities (thinking back to #5530 for example - we could have a locale option within there, allowing for specific variants for specific regions). Again though, we'd need to look at the fail-safe of if the options object is passed when a variant SVG no longer / never exists, we return the default icon (perhaps with an error in the returned JSON?). Should be a relatively small job though as part of the Get() method.

[ericcornelissen]

My suggestion would be that rather than creating a new entry in the JSON for the variant that we instead add a new, optional variant entry taking a value of "filled", "outlined" or "variant". This would avoid the implication that it's a separate brand and allow us to reserve those 3 modifiers by disallowing their use in the slug entry.

👍

They could then be implemented in the package through the addition of an options parameter to simpleIcons.Get() (which we've had brief discussion on elsewhere); Pass variant:true to the options parameter and it will return the relevant SVG if present, or the default if not.

Good idea, though I would prefer something clearer than varient:true, but we can work on the details of that later 😉

I don't know if we could do anything with the require statement, redirecting require('simple-icons/icons/brand_variant') to simple-icons/icons/brand if the variant doesn't exist.

There is something for that, you an specify that in package.json (only supported in newer version of NodeJS), but it would basically require an entry for every icon. Which we could add behind the scenes as a publish step, but I think we shouldn't preemptively do that.

It might also be worth us looking to have a fail-safe whereby if a variant file isn't found, the API defaults to returning the base brand. That way, should a brand update their logo and only require a single variant, it's not considered a breaking change for us to 'remove' the variants.

That would be pretty easy in the NodeJS package's main import but, in my opinion, unrealistic when it comes to the SVGs and and individual imports. I think the easiest solution is to just have the variant SVG be the same SVG as the original in case it changes. It should be unlikely that there is another rebrand before we have a chance to remove the duplicate, and if so it isn't the end of the world if the variant is outdated for one release.

[dzintars]

Just an extra confirmation form https://fonts.google.com/icons?selected=Material+Icons that there is need for icon style variations. As you can see they use filled, outlined, etc. icon sets.