Some logos are almost invisible on dark backgronds, e.g.,
https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars

It'd be great if there was a light version of them as well.
It _may_ not be necessary to have separate light/dark versions
perhaps it could be possible to specify a logoFillColor?
ie, the github.svg contains
<path fill="#333333" d=".... />
logoFillColor could specify "#FFF" to replace #333333
@bkdotcom
Yeah, i think that would be the best route to go,
I've played around with it previously,
The problem i ran into is that the svg's are converted to base64 pretty early on.
May be better if they were handled similar to the badge style templates.
I looked at some of the svgs more closely after my comment... I'm wondering if we give the "primary" fill a class of "color"... and any additional fills "colorB", "colorC", etc
ie, the bitcoin logo has two colors..
edit:: github only allows two colors. should we allow someone to specify #F00 ?
If you download the GitHub logos they do provide a light and a dark version.
should we allow someone to specify #F00 ?
I think allowing arbitrary colors is a step too far. Explicitly providing a dark and light version (where applicable) fixes the issue and is consistent with upstream specs.
For the API, my first thought is that if we have light and dark logos, we should detect which one to use in code so it just happens automagically and the user doesn't need to specify. Even if that needs to be tuned in code, that seems like a pleasant way to go about this.
If that doesn't work well enough, let's add a separate query parameter e.g. ?logoShade=light.
That should be a little cleaner overall than the simpler thing, ?logo=github-light, particularly if down the line we implement a parameter like ?defaultLogo which shows the logo that corresponds with the requested service. That's something we've talked about before.
We could also do something like (based on current templates for styles):
?logoColor=white
<svg xmlns="http://www.w3.org/2000/svg" width="40" height="40" viewBox="12 12 40 40">
{{ supportedColors = { 'grey': '333333', 'white': 'FFFFFF' }; }}
{{ logoColor = supportedColors[logoColor in supportedColors ? logoColor : 'grey']; }}
<path fill="#{{logoColor}}" d="M32,13.4c-10.5,0-19,8.5-19,19c0,8.4,5.5,15.5,13,18c1,0.2,1.3-0.4,1.3-0.9c0-0.5,0-1.7,0-3.2 c-5.3,1.1-6.4-2.6-6.4-2.6C20,41.6,18.8,41,18.8,41c-1.7-1.2,0.1-1.1,0.1-1.1c1.9,0.1,2.9,2,2.9,2c1.7,2.9,4.5,2.1,5.5,1.6 c0.2-1.2,0.7-2.1,1.2-2.6c-4.2-0.5-8.7-2.1-8.7-9.4c0-2.1,0.7-3.7,2-5.1c-0.2-0.5-0.8-2.4,0.2-5c0,0,1.6-0.5,5.2,2 c1.5-0.4,3.1-0.7,4.8-0.7c1.6,0,3.3,0.2,4.7,0.7c3.6-2.4,5.2-2,5.2-2c1,2.6,0.4,4.6,0.2,5c1.2,1.3,2,3,2,5.1c0,7.3-4.5,8.9-8.7,9.4 c0.7,0.6,1.3,1.7,1.3,3.5c0,2.6,0,4.6,0,5.2c0,0.5,0.4,1.1,1.3,0.9c7.5-2.6,13-9.7,13-18.1C51,21.9,42.5,13.4,32,13.4z"/>
</svg>
_(probably a better way than the example above)_
This way each logo can have its own supported colors where a company only wants specific colors associated with their logo.
eg Discord:

Or to makes it easier for users to find the different allowed colors:
?logoVariant=1
variants = ['7289DA', 'FFFFFF', '99AAB5', '2C2F33', '2C2F33'];
logoColor = variants[logoVariant < variants.length ? logoVariant : 0];
we should detect which one to use in code so it just happens automagically and the user doesn't need to specify.
Yeah that should work quite well,
I've done something similar before in a few projects,
The main thing to note is the perceived brightness of colors:
Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000
Also here's a pretty good post about How to automatically choose a label color to contrast with background which uses the above formula.
A few more considerations:
Storing and updating allowed colours for every logo does add some maintenance overhead to every logo accepted. Not a large overhead, but it does scale linearly with the number of logos stored.
In some cases, it may be necessary to store combinations of allowed colours, Some organisations may define combinations of colours that are valid together. Defining a flexible way to encode and use lots of different marketing rules for lots of different logos may not be as trivial as a single list of valid colours.
In some cases it may not be clear because there is not sufficient guidance issued. In a case where guidance is not available, would all colour transformations be valid, or none?
Agreed it does add a fair amount of overhead, but hopefully their guidelines won't change too often, so _should_ in most cases be an update once and forget kind of deal.
Yeah wasn't really sure on a good way to handle the multi color logos, maybe just something simple like:
[['44cc11', '333333'], ['10aded', 'cccccc']];
For when there is predefined combinations of colors, Not sure about cases where its just a list of colors that are allowed to be used together in any place.
When no guidelines are provided we could use a predefined list of colors (possibly same colors as colorscheme.json) for the ?logoVariant and allow ?logoColor for any other color.
But i think for the start it may be better to just go with @paulmelnikow's idea and auto detect if the logo should be a light or dark variant (for non colored logos).
Also i would guess ~99% of the time it would be the light variant for anything but social style badges (which would always be the dark variant as the label background color/colorA does not change)
But i think for the start it may be better to just go with @paulmelnikow's idea and auto detect if the logo should be a light or dark variant (for non colored logos).
:+1: Finding or making a light/dark version of each of the current supported logos would also be an opportunity to review the branding resources for each one which might inform the requirements of a more complex solution.
Since #1810 thanks to @RedSparr0w a color can be specified using ?logoColor=:
https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars
https://img.shields.io/github/stars/django/django.svg?logo=github&label=Stars&logoColor=white
I think it would be nice to automatically detect light and dark, or let the user choose "light" or "dark" without having to pick a color. We did make progress here, so maybe that's best tracked in a new issue.
Ah, I missed that above, yeah I think it may be better in a new issue as to not get buried.
Would definitely be a good option to add.
Sounds good. Opened #2431.
Most helpful comment
I think allowing arbitrary colors is a step too far. Explicitly providing a dark and light version (where applicable) fixes the issue and is consistent with upstream specs.